Libsass: Option zur Steuerung des CSS-Inline-Importverhaltens hinzufügen

Ich denke, der Wortlaut ist etwas irreführend. Wir erlauben nur den Import von CSS-Partials (Dinge, die mit .css enden, bleiben als tatsächlicher Import im Code). Auch Ruby Sass erlaubt dies standardmäßig nicht, aber einige Tools (auch AFAIK-Kompass) aktivieren dies standardmäßig für Ruby Sass. Ich bin mir auch nicht sicher, ob wir es wirklich standardmäßig deaktivieren möchten, da dies eine weitere potenziell brechende Änderung wäre.

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

Vollständige Offenlegung Ich denke immer noch, dass diese Funktion entfernt werden sollte. Unsere Anweisung ist, das zu tun, was Ruby Sass tut. Jede Abweichung von ihrer Implementierung beeinträchtigt die Portabilität und ist von einem Fehler nicht zu unterscheiden.

Auch Ruby Sass erlaubt dies standardmäßig nicht, aber einige Tools (auch AFAIK-Kompass) aktivieren dies standardmäßig für Ruby Sass

Das ist nicht unser Job. Dies gehört in den Bereich von Werkzeugen wie Wellington und Brille.

Ich bin mir auch nicht sicher, ob wir es wirklich standardmäßig deaktivieren wollen

Ich glaube vehement, dass es sollte.

Dies wäre eine weitere potenziell bahnbrechende Änderung

Das aktuelle Verhalten ist für Sass-Benutzer fehlerhaft.

Ich denke, es ist klar, dass ich für diese Funktion bin und wollte nur darauf hinweisen, dass der Bruch hauptsächlich darauf zurückzuführen ist, dass ich die Fehlermeldung für mehrdeutige Importe für libsass 3.3.0 implementiert habe. Abgesehen davon unterscheiden wir uns standardmäßig nur in der teilweisen Auflösung (einschließlich CSS-Erweiterung), und ich würde argumentieren, dass Sie normalerweise kein CSS mit demselben Namen neben einem Teilimport generieren oder haben. Unsicher, wann ich das als Option in der C-API implementieren werde. Mitwirkende willkommen;)

Ich denke, die ideale Situation wäre, dass beide diese Funktionen unterstützen. Das nächstbeste wäre, wie @xzyfer sagt, und zumindest, dass sie konsistent sind, auch wenn dies bedeutet, dass keiner von ihnen es unterstützt.

Sie sollten theoretisch in der Lage sein, von libsass zu ruby ​​sass zu wechseln, ohne dass etwas kaputt geht. Etwas zu haben, das dies wissentlich verhindern würde, ist eine schlechte Sache.

Sie sollten theoretisch in der Lage sein, von libsass zu ruby ​​sass zu wechseln, ohne dass etwas kaputt geht

Genau.

Das nächstbeste wäre, wie @xzyfer sagt, und zumindest, dass sie konsistent sind

Das werden wir tun.

Sass 4.0 wird eine Möglichkeit bieten, dies richtig zu machen.

Fantastisch! Ich kann es kaum erwarten.

@mgreter Ich habe mit @chriseppstein und @ nex3 über dieses Problem gesprochen. Wir haben entschieden, dass das Entfernen dieser Funktion die Benutzer wahrscheinlich verärgert, obwohl Inline-CSS-Importe die Ruby Sass-Kompatibilität erheblich beeinträchtigen. Dies ist eine seit langem nachgefragte Funktion in Ruby Sass, die aufgrund der Einschränkungen einer CSS-Obermenge nicht möglich war. Infolgedessen sind fast bestimmte Personen von diesem Verhalten abhängig.

Versuchen wir stattdessen, dies in 4.0 zu entfernen, da Benutzer Änderungen in Hauptversionen eher akzeptieren und weil wir eine offizielle Möglichkeit haben, CSS-Importe zu integrieren.

Wir haben kürzlich von einer viel älteren Version auf die neueste Version von Node umgestellt und mussten eine von uns verwendete Drittanbieter-Bibliothek aktualisieren, um mit der aktuellen Node-Version kompatibel zu sein. Jetzt sind die Dinge wegen dieses Fehlers überall kaputt. Ich verstehe, dass dieses Problem in libsass noch nicht behoben ist. Daher versuche ich rekursiv herauszufinden, zu welchen Versionen unserer Abhängigkeiten wir zurückkehren müssen, um dieses Problem zu beheben.

Also ein paar Fragen (Entschuldigung, wenn ich diese Informationen hier verpasst habe, ist dieser Thread etwas verworren):

1. In welcher Version von libsass wurde dieser Fehler eingeführt?
2. In welcher Version wird das Update ausgeführt - 3.5? 4,0?
3. Wann soll diese Version veröffentlicht werden? (Oder wurde es vielleicht schon veröffentlicht?)

In welcher Version von libsass wurde dieser Fehler eingeführt?

Ich kann nicht sicher sein. Ich denke, es war ungefähr 3.3.0, was sich in [email protected] befindet.

In welcher Version wird das Update ausgeführt - 3.5? 4,0?

Dies wird in 4.0 behoben, sobald @use landet. Benutzer können sich explizit für CSS-Importe anmelden.

Wann soll diese Version veröffentlicht werden?

Das kann man leider nicht sagen. Wahrscheinlich nicht in diesem Jahr.

Abgesehen davon, wenn Sie Node-Sass verwenden, können Sie einen benutzerdefinierten Importer für Noop-Importe für CSS-Dateien schreiben.

Wie @xzyfer sagte, versuchen Sie es mit einem benutzerdefinierten Importer. Ich hatte ein Problem, bei dem sich .scss-Dateien und .css-Dateien im selben Verzeichnis befanden. Hier ist der Importer, den ich für Node-Sass erstellt habe

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});
}

Getestet mit Node-Sass 4.5.2 Libsass 3.5.0-Beta2