Parcel 创建者 Devon Govett 发布了 最新消息，即 Parcel CSS
一个用 Rust 编写的 CSS 解析器、转换器和压缩器。
不错。CSS 世界确实需要这样的处理方式革新。
我 几周前刚写过
您知道 esbuild 如何彻底改变了 JavaScript 处理世界吗？也许我们需要一个 cssbuild？它可以处理导入并进行捆绑（我们通常依赖 Sass 来完成）。重点在于极快的速度。也许它是基于插件的，并且与 PostCSS API 兼容，以便现有的 PostCSS 插件可以在其上工作。也许它可以生成 sourcemap 并进行修改。也许它也可以运行您的 Sass，我不知道。但像这样激发 CSS 生态系统的东西可能会很酷。
接近！看起来它不进行捆绑（至少独立时不进行）。我想它必须为此发明一种语法，因为我认为 Sass 有点后悔它像原生 CSS 一样使用@import的方式的模糊性，我不会责怪任何人不想走这条路。这绝对是一片棘手的领域，因为发明语法有点把它归入不同的工具类别。但我认为这值得一试，因为将 CSS 分解成更小的文件但在开发中将其捆绑在一起就像……人们做的事情，我可以看到人们非常想使用它，而不必一定要使用 Parcel（可以捆绑）。
那么为什么要将您的 CSS 通过这个工具运行呢？从文档来看，您可能希望这样做是因为……
（最初，我以为它利用其他工具来完成这些任务，因为像 Autoprefixer 和 cssnano 这样的工具出现在项目的package.json文件中，但正如下面的 Devon 的评论所证实的那样，Parcel CSS 是这些工具的替代品，它不使用它们。）
但还有一个！在我看来，Parcel CSS 的杀手级功能是他们所谓的“语法降低”，这意味着您可以今天使用“未来”的 CSS（例如，嵌套），因为它会被处理成浏览器可以理解的东西，就像 Babel 在 JavaScript 中做的那样。这在精神上类似于 postcss-preset-env。
并且至关重要的是，它很快
Parcel CSS 会成为一个生态系统吗？
所以我想最大的问题是：如果 Parcel CSS 成为首选的 CSS 解析器，我们会得到插件吗？如果我们这样做，它会成为一个像 PostCSS 插件 那样强大的生态系统吗？
Parcel CSS 是 cssnano、autoprefixer 和 postcss-preset-env 的替代品。它不使用它们。您在 package.json 中看到的依赖项是用于测试、基准测试和生成有关哪些浏览器需要哪些前缀的数据的开发依赖项（我们重用 autoprefixer 的数据，但不重用其实现）。
令人印象深刻！将更新帖子以明确说明这一点。
这确实是 Sass 使用
@use和@forward的新模块系统背后的理念。哦……这很有趣。已经使用 Parcel 2 一段时间了，我非常喜欢它。
问题
我刚刚阅读了有关 Parcel 转换器设置 的文档。
这是否适用于 Sass (.scss) 文件，还是只适用于原始 CSS？
是的，它可以工作。SASS 将首先编译成 CSS（包含在默认的 Parcel 配置中），然后通过您在那里配置的 CSS 管道运行。
感谢 Devon……这是一个好消息！
我现在希望可以丢弃一些明确定义的 PostCSS 插件。
不错！看到 CSS 工具的这一进步真是令人兴奋。非常期待它未来的发展和进步。
我也有文章结尾提出的问题。归根结底，我认为这不会成为下一个 PostCSS。他们专注于解析器/AST 工具，使其尽可能快速和友好，然后让插件处理变异的方法似乎是生态系统的正确方法。
希望 Parcel CSS 能朝这个方向发展。虽然 Parcel CSS 确实内置了四大等效功能（Autoprefixer、cssnano、postcss-modules 和 postcss-preset-env），但它缺少了 其他增强功能的完整目录。此外，如果我想交换内置功能怎么办？例如，在 CSS 压缩器工具领域有很多竞争……如果我想用输出更小的压缩器替换 parcel 的压缩器怎么办？
当然，我可以关闭 parcel 的压缩功能，然后通过像 PostCSS 这样的其他 Node AST/工具运行我的 CSS……但这确实开始削弱使用 Rust 的好处，不是吗？如果我必须在 Node 中解析我的 CSS……它也可能从那里开始，然后我就可以消除一个依赖项。
以上都不是为了贬低该工具的成就。看到第一个主要基于 WASM 的 CSS AST 工具（至少对我来说）确实令人兴奋。而且，如果我们必须有一个插件链，没有任何东西可以阻止任何人在其上构建自己的插件 Parcel CSS 解析器……尽管我当然希望它开箱即用；)
Devon（和团队）辛苦了！