Libsass: Ajouter une option pour contrôler le comportement d'importation en ligne CSS

Je pense que le libellé est un peu trompeur. Nous n'autorisons que les importations de partiels css (les éléments se terminant par .css resteront en tant qu'importation réelle dans le code). Ruby Sass ne le permet pas non plus par défaut, mais quelques outils (la boussole AFAIK également) l'activent par défaut pour Ruby Sass. Je ne sais pas non plus si nous voulons vraiment le désactiver par défaut, car ce serait un autre changement potentiellement cassant.

class CSSImporter < Sass::Importers::Filesystem
  def extensions
    super.merge('css' => :scss)
  end
end
Sass::Plugin.options[:filesystem_importer] = CSSImporter

Divulgation complète Je pense toujours que cette fonctionnalité devrait être supprimée. Notre directive est de faire ce que fait Ruby Sass. Tout écart par rapport à leur implémentation rompt la portabilité et ne peut être distingué d'un bogue.

Ruby Sass ne le permet pas non plus par défaut, mais quelques outils (boussole AFAIK également) l'activent par défaut pour Ruby Sass

Ce n'est pas notre travail. Cela appartient au domaine des outils comme Wellington et les lunettes.

Je ne sais pas non plus si nous voulons vraiment le désactiver par défaut

Je crois fermement que cela devrait.

ce serait un autre changement potentiellement révolutionnaire

Le comportement actuel est interrompu en ce qui concerne les utilisateurs de Sass.

Je suppose qu'il est clair que je suis en faveur de cette fonctionnalité et que je voulais juste souligner que la rupture est principalement due au fait que j'ai implémenté le message d'erreur pour les importations ambiguës pour libsass 3.3.0. À côté de cela, nous ne différons que par défaut dans la résolution partielle (incluant également l'extension css), et je dirais que normalement vous ne générez pas ou n'avez pas de css avec le même nom à côté d'une importation _partial_. Je ne sais pas quand je viendrai pour implémenter cela en option sur l'API C. Les contributeurs sont les bienvenus;)

Je pense que la situation idéale serait qu'ils prennent tous les deux en charge ces fonctionnalités. La meilleure chose à faire serait comme @xzyfer le dit et au moins les avoir cohérents, même si cela signifie qu'aucun d'eux ne le soutient.

Vous devriez pouvoir passer de libsass à ruby ​​sass en théorie sans que rien ne se brise. Avoir quelque chose qui empêcherait sciemment que cela se produise est une mauvaise chose.

Vous devriez pouvoir passer de libsass à ruby ​​sass en théorie sans rien casser

Exactement.

La prochaine meilleure chose serait comme le dit @xzyfer et au moins les avoir cohérents

C'est ce que nous allons faire.

Sass 4.0 apportera un moyen de le faire correctement.

Fantastique! Je ne peux pas attendre.

@mgreter J'ai parlé à @chriseppstein et @ nex3 de ce problème. Nous avons décidé que même si les importations en ligne CSS cassent considérablement la compatibilité Ruby Sass, la suppression de cette fonctionnalité risque de déranger les utilisateurs. Cela a été une fonctionnalité demandée depuis longtemps dans Ruby Sass, ce qui n'était pas possible en raison des limitations d'être un sur-ensemble CSS. En conséquence, presque certaines personnes dépendent de ce comportement.

Essayons plutôt de supprimer cela dans la version 4.0, car les utilisateurs acceptent davantage les changements de rupture dans les versions majeures, et parce que nous aurons un moyen officiel pour intégrer les importations CSS.

Nous sommes récemment passés à la dernière version de Node à partir d'une version beaucoup plus ancienne et avons dû mettre à niveau une bibliothèque tierce que nous utilisons, pour être compatible avec la version actuelle de Node. Maintenant, les choses sont cassées partout à cause de ce bug. Je comprends que ce problème n'est pas encore résolu dans libsass, donc j'essaie de déterminer récursivement à quelles versions de nos dépendances nous aurions besoin de revenir pour se débarrasser de ce problème.

Alors, quelques questions (excuses, si j'ai manqué cette info ici, ce fil est un peu alambiqué):

1. Quelle version de libsass ce bogue a-t-il été introduit?
2. Quelle est la version du correctif - 3.5? 4.0?
3. Quand la sortie de cette version est-elle prévue? (Ou a-t-il déjà été publié, peut-être?)

Quelle version de libsass ce bogue a-t-il été introduit?

Je ne peux pas en être certain. Je pense que c'était autour de 3.3.0 qui est dans [email protected].

Quelle est la version du correctif - 3.5? 4.0?

Cela sera corrigé dans 4.0 une fois que @use atterrira. Cela permettra aux gens de s'inscrire explicitement aux importations CSS.

Quand la sortie de cette version est-elle prévue?

Impossible de dire malheureusement. Pas susceptible d'être cette année.

En aparté, si vous utilisez node-sass, vous pouvez écrire un importateur personnalisé pour les importations noop pour les fichiers .css.

Comme @xzyfer l'a dit, essayez un importateur personnalisé, j'ai eu un problème où nous avions des fichiers .scss et des fichiers .css dans le même répertoire, et voici l'importateur que j'ai créé pour node-sass

importer: function(url, prev, done) {
    // Use this to import scss files, instead of css ones
    let updatedUrl = url;
    if (!url.endsWith('.scss') && !url.endsWith('.css')) { // Also don't change ones already explicitly set to .css
        updatedUrl += '.scss';
    }
    grunt.verbose.writeln(`Changed ${url} into ${updatedUrl}`);
    done({file: updatedUrl});
}

Testé avec node-sass 4.5.2 libsass 3.5.0-beta2