Frisch erschienen von Devon Govett, dem Erfinder von Parcel, ist Parcel CSS.
Ein CSS-Parser, Transformer und Minifier, geschrieben in Rust.
Gut. Die CSS-Welt könnte eine kleine Umwälzung durch Verarbeitung wie diese gebrauchen.
Ich habe vor ein paar Wochen geschrieben
Du weißt, wie esbuild die Welt der JavaScript-Verarbeitung auf den Kopf gestellt hat? Vielleicht brauchen wir ein cssbuild? Es würde Imports verarbeiten und Bundling betreiben (etwas, wofür wir uns normalerweise auf Sass verlassen). Das Ziel wäre extreme Geschwindigkeit. Vielleicht wäre es Plugin-basiert und kompatibel mit der PostCSS-API, sodass bestehende PostCSS-Plugins darauf funktionieren würden. Vielleicht könnte es Sourcemaps erstellen und Modifikationen vornehmen. Vielleicht würde es auch dein Sass ausführen, ich weiß es nicht. Aber etwas, das das CSS-Ökosystem so beflügelt, könnte cool sein.
Fast! Es scheint, dass es kein Bundling (standalone sowieso) tut. Ich schätze, es müsste einfach eine Syntax dafür erfinden, da ich denke, dass Sass das mehrdeutige Verhalten von @import, genau wie natives CSS, bedauert, und ich würde es niemandem verübeln, diesen Weg nicht gehen zu wollen. Es ist sicherlich heikles Terrain, da die Erfindung von Syntax das Ganze in eine andere Kategorie von Werkzeugen einordnet. Ich denke aber, es wäre es wert, denn das Aufteilen von CSS in kleinere Dateien, aber deren Bündelung in der Entwicklung ist wie... eine Sache, die Leute tun, und ich könnte mir vorstellen, das wirklich nutzen zu wollen, ohne sich unbedingt an Parcel (das bündeln kann) binden zu müssen.
Warum also dein CSS durch dieses Ding laufen lassen? Laut der Dokumentation sieht es so aus, als würdest du das tun, weil...
- es ein Minifier ist,
- es Vendor-Präfixe hinzufügt,
- es als CSS-Module verarbeiten kann (die klassische Bibliothek, nicht die nativen) und
- du Sourcemaps erhältst.
(Ursprünglich dachte ich, es würde für diese Aufgaben andere Tools nutzen, da Tools wie Autoprefixer und cssnano in der package.json-Datei des Projekts auftauchten, aber wie der Kommentar von Devon unten bestätigt, ist Parcel CSS ein Ersatz für diese, es nutzt sie nicht.)
Aber es gibt noch eins! Für mich scheint das Killer-Feature von Parcel CSS das zu sein, was sie "Syntax-Senkung" nennen, was bedeutet, dass du "zukünftiges" CSS heute nutzen kannst (wie z.B. Nesting), indem du es zu Dingen verarbeiten lässt, die Browser verstehen, so wie Babel es bei JavaScript tut. Es fühlt sich im Geiste ähnlich an wie postcss-preset-env.
Und entscheidend ist, es ist schnell
Wird Parcel CSS ein Ökosystem?
Also, ich schätze, die große Frage ist: Wenn Parcel CSS zum bevorzugten CSS-Parser wird, bekommen wir dann Plugins? Und wenn ja, wird es dann ein robustes Ökosystem wie PostCSS-Plugins?
Parcel CSS ist ein Ersatz für cssnano, autoprefixer und postcss-preset-env. Es nutzt sie nicht. Die Abhängigkeiten, die Sie in package.json gesehen haben, sind Dev-Abhängigkeiten für Tests, Benchmarking und die Generierung von Daten darüber, welche Präfixe für welche Browser benötigt werden (wir verwenden die Daten von Autoprefixer wieder, aber nicht seine Implementierung).
Beeindruckend! Ich werde den Beitrag aktualisieren, um das klarzustellen.
Das ist tatsächlich die Idee hinter Sass' neuem Modulsystem mit
@useund@forward.Oooh... das ist interessant. Ich benutze Parcel 2 schon eine Weile und liebe es.
Frage
Ich habe gerade die Dokumentation über die Einrichtung von Parcel-Transformer gelesen.
Funktioniert das mit Sass (.scss) Dateien oder nur mit rohem CSS?
Ja, das funktioniert. SASS wird zuerst zu CSS kompiliert (im Standard-Parcel-Config enthalten) und dann durch die von Ihnen dort konfigurierte CSS-Pipeline geleitet.
Danke Devon... das sind tolle Neuigkeiten!
Ich kann jetzt hoffentlich einige explizit definierte PostCSS-Plugins verwerfen.
Schön! Es ist wirklich aufregend, diesen Schritt in der CSS-Tooling-Welt zu sehen. Ich bin wirklich gespannt, wohin es sich entwickelt und wie es voranschreitet.
Auch ich hatte jedoch die Frage am Ende des Artikels. Am Ende des Tages kann ich mir nicht vorstellen, dass dies das nächste PostCSS wird. Ihr Ansatz, sich auf ein Parser/AST-Tool zu konzentrieren, es so schnell und benutzerfreundlich wie möglich zu gestalten und dann Plugins die Mutationen übernehmen zu lassen, scheint der richtige für ein Ökosystem zu sein.
Hoffentlich bewegt sich Parcel CSS in diese Richtung. Während Parcel CSS definitiv die vier wichtigsten Äquivalente integriert hat (Autoprefixer, cssnano, postcss-modules und postcss-preset-env), fehlen ihm ein ganzes Katalog von anderen Verbesserungen. Außerdem, was ist, wenn ich eingebaute Funktionen austauschen möchte? Es gibt viel Wettbewerb im Bereich der CSS-Minifier-Tools, zum Beispiel... was ist, wenn ich Parcel-Minifizierung gegen eine mit geringerem Output austauschen möchte?
Sicher, ich kann die Minifizierung von Parcel deaktivieren und mein CSS durch ein zusätzliches Node AST/Tool wie PostCSS laufen lassen. Aber das verwässert den Vorteil der Verwendung von Rust, nicht wahr? Wenn ich mein CSS in Node parsen muss, könnte es genauso gut dort anfangen und dann kann ich eine Abhängigkeit eliminieren.
Nichts davon soll die Leistung des Werkzeugs schmälern. Es ist wirklich aufregend (zumindest für mich), das erste große WASM-gestützte CSS-AST-Tool zu sehen. Und hey... wenn wir unbedingt eine Plugin-Kette brauchen, hindert uns niemand daran, unsere eigene auf dem Parcel CSS-Parser aufzubauen... obwohl ich das natürlich Out-of-the-Box lieben würde ;)
Großartige Arbeit, Devon (und Team)!!!!