Haml: Demande de fonctionnalité : Importer un dossier

Je suis sceptique quant à l'utilité de cela. Je ne pense pas qu'avoir à répertorier manuellement tous les fichiers pertinents soit vraiment si pénible. En outre, il semble que cela puisse entraîner le risque de ne pas obtenir d'erreurs de compilation réelles lorsqu'un fichier que vous pensez exister n'existe pas. Au lieu de cela, les styles disparaissent apparemment arbitrairement.

Je comprends votre argument, cependant, je ne pense pas que vous voyez l'autre type de situation qui est nécessaire. Actuellement, j'ai un dossier qui contiendra plus de 60 fichiers Sass. Sans la possibilité d' @importer un dossier, je dois conserver un fichier qui importe chaque fichier individuellement.

L'inclusion de chaque fichier individuellement pose de nombreux problèmes. Premièrement, si vous oubliez d'inclure un fichier, vous ne recevez pas d'avertissement. Ensuite, si vous avez une équipe de développeurs travaillant sur Sass, chacun doit se rappeler d'importer le fichier manuellement après l'avoir créé dans le dossier. Dépendre des gens pour faire la bonne chose finira par casser.

De plus, nous avons la priorité que l'importation d'un dossier est une "bonne chose". L'instruction import de Java vous permet d'importer des packages entiers ou des classes spécifiques de ces packages.

L'ordre des importations est important dans le cas général car les sélecteurs de même poids se résolvent en fonction de l'ordre des documents. Globbing signifie que l'ajout d'un fichier peut modifier l'ordre de résolution global des sélecteurs de manière inattendue.

De tels problèmes d'ordre ne sont pas présents dans le code et là où ils se trouvent (comme ruby), il n'y a pas une telle fonctionnalité.

Je serais intéressé de voir s'il existe un moyen de le faire dans Sass sans modifier le mécanisme d'importation du noyau sass. Cela permettrait aux cadres et aux personnes utilisant sass de développer leur propre système de globalisation comme bon leur semble. Par exemple:

<strong i="8">@import</strong> file-list("foo/*.sass");

Nous avions l'habitude d'avoir une logique d'analyse spéciale pour @import qui aurait empêché cela, mais ce n'est plus le cas.

Le problème avec l'autorisation d'importations vraiment dynamiques (telles que les fonctions via) est que la structure de dépendance d'un document devient alors impossible à comprendre dynamiquement. Cela signifie que la mise en cache et la compilation sélective deviennent beaucoup moins utiles.

Pour les problèmes d'ordre, nous pourrions toujours trier les fichiers par ordre alphabétique ou quelque chose pour arriver à un ordre déterministe (bien qu'arbitraire). Cela pose toujours le problème que la commande pourrait changer et perturber la fonctionnalité si le nom d'un fichier change, cependant.

Vraisemblablement, une telle approche via le globbing impliquerait l'utilisation de sélecteurs imbriqués pour éviter de tels problèmes.

À mon avis, l'importation d'une arborescence complète de fichiers n'a qu'une utilité marginale par rapport à l'approche d'importation explicite et encourage l'utilisateur à considérer les problèmes de priorité. Si nous ajoutons une telle fonctionnalité, j'aimerais qu'elle soit plus générale qu'au niveau du répertoire.

Enfin, je pense que vous avez raison de dire que l'introduction d'un glob qui était en dehors du graphique de dépendance et qui n'apparaît que sous la forme d'importations uniques dans le moteur sass signifie qu'il est plus difficile d'invalider des fichiers lorsque de nouvelles dépendances correspondant au glob apparaissent.

Je suis d'accord que l'importation d'un dossier conduirait à un ordre ambigu des fichiers importés. Cependant, cela devrait être à l'utilisateur de décider si c'est la bonne chose pour eux. Il s'adaptera à certaines situations mais pas à d'autres. Il est tout à fait possible d'envisager un système où le contenu d'un dossier ne cible pas les mêmes éléments (le mien ne le fait pas).

Tout comme l'importation de fichiers spécifiques fonctionne. il convient à certaines situations mais pas à d'autres.

Le choix devrait appartenir au développeur.

Il est trop facile pour un utilisateur d'avoir des feuilles de style qui dépendent de l'ordre et de ne pas le savoir. N'importe quoi pourrait déclencher une réorganisation et créer des bugs de mise en page qui seraient très difficiles à traquer. Et il ne serait pas assez clair que l'importation d'un répertoire laisserait quelqu'un ouvert à de tels problèmes. Commander via le nom de fichier serait probablement une solution suffisante à cela, donc ce n'est pas un obstacle sérieux.

L'extension que j'envisagerais autoriserait les globs de fichiers standard - probablement ceux pris en charge par Dir.glob . Cela pourrait être résolu au moment de la compilation et fournirait un degré de puissance raisonnable.

Je suis encore loin d'être convaincu de l'utilité, cependant.

Il est important de considérer que la commande via Dir.glob dépend du système de fichiers et peut changer d'une plate-forme à l'autre. J'ai en fait été mordu par cette différence entre Mac et Linux. Donc, si nous finissons par implémenter une telle fonctionnalité, il est important pour nous de trier la liste selon une approche bien documentée et facile à comprendre (par exemple, tri en casse)

Je suis aussi encore un peu penché contre cette fonctionnalité. L'approche d'importation utilisée par Compass n'a pas vraiment été une charge de maintenance. Cependant, c'est certainement une fonctionnalité couramment demandée. Je pense que cela a été mentionné sur la liste de diffusion et sur Twitter environ 4 ou 5 fois maintenant.

Nous allons certainement ordonner les fichiers de manière déterministe d'une manière ou d'une autre. Le tri upcase vs downcase est une question intéressante... nous devrions probablement faire downcase avec upcase comme bris d'égalité (car cela permettra des liens sur les systèmes de fichiers sensibles à la casse).

Je suis d'accord. Je suis un peu contre le fait de pouvoir passer un paramètre directement à Dir.glob. Cela semble vraiment être une fonctionnalité inutile. Pouvez-vous imaginer un scénario où il est avantageux d'avoir ce degré de contrôle ?

Il semble que les deux options suivantes devraient suffire :
-Cherry choisir des fichiers en utilisant @import
-Importer un répertoire entier en utilisant @import folder_name

De plus, je pense que l'alphabétique fonctionnera très bien. Nous devons juste nous assurer qu'il est documenté.

L'importation de répertoires via <strong i="5">@import</strong> dir est trop ambiguë avec l'importation de fichiers individuels. Nous devons absolument ajouter au moins * globs.

Toujours pas convaincu, cependant.

c'est utile si vous avez différents "styles" pour une page. Exemple:
générique/ (xx fichiers sass ici)
style1/ (xx fichiers sass ici qui ajoutent/écrasent les styles à ceux du générique)
style2/ (xx fichiers sass ici qui ajoutent/écrasent les styles à ceux du générique)
style1.sass (simplement : @import générique/_, style1/_)
style2.sass (simplement : @import générique/_, style2/_)

Pourquoi ne pourriez-vous pas simplement avoir _generic.sass qui importe tout dans le répertoire générique ?

Je ne pense pas qu'il s'agisse de ce qui peut ou ne peut pas être fait autant qu'ils devraient le faire. En fin de compte, l'ordre des feuilles de style est important et je veux donc que l'utilisateur y réfléchisse. Il est vrai que les bibliothèques qui définissent uniquement les mixins et les variables sont indépendantes de l'ordre, tout comme les feuilles de style étendues - mais je m'inquiète de fournir une capacité générale qui sera mal utilisée.

Définir des « feuilles de style délimitées » ?

Feuilles de style qui imbriquent la plupart ou la totalité de leurs sélecteurs. par exemple body.foo

Ceux-ci ne sont pas garantis d'être indépendants de l'ordre. Une autre feuille de style ailleurs pourrait définir body.foo ... , ou quelque chose d'autre avec une spécificité plus élevée.

Ensuite, vous n'avez vraiment pas de framework de travail car vos fichiers ne sont pas séparés correctement.

Il existe de nombreuses façons pour les gens de bousiller leur CSS. Nous pouvons leur fournir cette solution et expliquer quand elle doit être utilisée par rapport à l'importation de fichiers individuels.

En n'implémentant pas cette fonctionnalité, vous offrez aux développeurs qui souhaitent implémenter des feuilles de style étendues ces deux choix :
1) importer manuellement chaque fichier indépendamment ( ce qui peut provoquer des erreurs de son propre parce qu'il ne vous dit pas quand vous avez manqué un fichier)
2) Implémentez un système de build pour ajouter dynamiquement ces fichiers (ce qui est un gaspillage car il y aura plusieurs personnes implémentant la même chose)

Ce n'est certainement pas le cas que toute dépendance à l'ordre des feuilles de style étendues soit le résultat d'une mauvaise séparation des préoccupations. Envisager:

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

Cette feuille de style est bien séparée, mais toujours dépendante de l'ordre.

Dans tous les cas, l'idée que l'on peut s'attendre à ce que tout le monde utilisant cette fonctionnalité comprenne les risques est fausse. La seule façon de s'assurer que tout le monde comprend dans quel ordre ses feuilles de style seront importées est de le spécifier explicitement.

Dans l'ensemble, les feuilles de style à portée seront indépendantes de l'ordre, mais il peut arriver que l'ordre compte même lorsque les préoccupations sont correctement séparées.

Ignorer silencieusement les importations qui ne sont pas trouvées n'est plus un problème dans sass3. Seules les importations CSS seront ignorées en silence.

J'ai un fichier sass qui en importe environ 60 autres. Je le change lorsque des fichiers sont ajoutés ou supprimés et je pense toujours à la commande quand je le fais. Cela ne m'a jamais semblé être un fardeau, mais plutôt une étape nécessaire.

Si mes importations ne sont pas trouvées (je spécifie toujours .sass pour les importations), mes tests échouent.

Il y a un ajout : le plus simple possible et pas plus simple.

Mon instinct me dit que cela rend les choses trop simples et que toutes les économies de temps sont perdues en une seule session de débogage. Je vote pour que nous mettions cela de côté pour le moment. Si quelqu'un veut créer un plugin sass qui offre cette capacité, je serais très intéressé de voir comment cela fonctionne pour ces utilisateurs.

Je pense que le point de Richard était qu'il n'y a pas d'erreur lorsqu'un partiel est créé mais qu'aucune importation n'est ajoutée pour celui-ci. Je suppose que cela pourrait être atténué en recherchant les partiels inutilisés et en imprimant des avertissements pour eux.

Je vais aller de l'avant et fermer ceci.

gah, ça craint... j'ai un dossier appelé page_specific/ dans les actifs de mon application rails...
ceux-ci doivent tous être compilés dans le gros blob d'actifs, et ils sont chacun complètement enveloppés dans
corps#page1 {}, corps#page2 {}, etc...

il n'y a aucune chance qu'ils soient dépendants de la commande, et franchement tout ce "vous allez manquer de l'utiliser ! non !!!!!!" la merde est insultante.

si un utilisateur de cette fonctionnalité découvre que l'ordre est important, il peut simplement importer les fichiers dans un ordre explicite, ou refactoriser les styles pour qu'ils ne dépendent pas de l'ordre... obliger tout le monde à contourner manuellement cette fonctionnalité manquante est une ordure paternaliste > : (

nous pouvons sûrement penser à un moyen de minimiser ce problème mineur de commande. l'ordre déterministe est un début. l'appeler @import-dir, et la documentation du problème de commande potentiel serait également utile. rails fournit déjà require_tree, et les choses semblent bien fonctionner. la seule exception est que les fichiers sont compilés individuellement, ce qui laisse tomber mes mixins et variables sur le sol. Je note que les mixins sont la seule partie qui a été placée comme explicitement indépendante de l'ordre, alors pourquoi cela ne peut-il pas fonctionner pour le sass alors que cela fonctionne pour tout le monde?

https://github.com/chriseppstein/sass-globbing

@chriseppstein génial ! (et désolé d'avoir fulminé comme un maniaque tout le monde)