Add support for Lighning CSS

Feature requests
1

There were already requests for PostCSS support, but keats declined it as not being Rust-based, which is a good argument.

Well, let me introduce you all to Lightning CSS. It’s a CSS powerhouse, which can bundle, transform, and minify CSS and replace 30-ish PostCSS plugins. The most important feature for everyone would be auto-prefixing, I suppose. It can also generate source maps (including from already generated maps), which will make it a good addition to Zola’s CSS pipeline, perhaps even replace it, since one can extend its functionality with custom Visitors.

The best thing: It’s written in Rust and is available as a crate. I really urge you to look into this, because I think this is a better option than interfacing with or bootstrapping Node, or whatever nonsense it is that others do :stuck_out_tongue:

8 Likes
2

I have now tried it out in a fork. The tests run fine, and I could run it on my personal website without any hiccups :+1:

4 Likes
3

This looks quite promising - @keats what are your thoughts? It seems to align with some of your past comments (which I appreciate and align with) - doesn’t pull in node, still fits into the single binary concept

4

To give this even more weight: Andrey Sitnik, the creator of PostCSS, urges others to start using Lightning CSS instead, too :slight_smile:

2 Likes
5

I have just now realized that the development does not happen on master, but on next and have updated the commits accordingly: compare/next...lightning-css

@keats is there any interest in this becoming a part of Zola?

6

Does this pass all the tests? It might be better to just open a PR and continue the discussion there.

7

The tests needed a small adjustment, but they pass. I decided to follow the “do not create a PR adding a new feature without discussing it first” rule :smile:

2 Likes
8

Are there issues doing sass → lightning? Eg some syntax that might not be valid in Sass.

Either way which part of it is appealing to people? The minifying, the vendor prefixes (is that still a thing now?) or the syntax lowering? I’m assuming we will not add configuration options for it in config.toml but it should still be a configuration option to have it enabled.

9

Are there issues doing sass → lightning? Eg some syntax that might not be valid in Sass.

AFAIK, grass outputs valid CSS, and Ligthning parses and rewrites valid CSS, so no issues there.

Either way which part of it is appealing to people?

  1. Better minifying (in comparison to Sass, esbuild, cssnano)
  2. Support for newer CSS features (colours, ,ath, etc.) and CSS modules, and the backport of those to the browsers matching the defaults Browserslist query. This is basically what many people who askes for PostCSS wanted (excluding those, who were actually asking for Tailwind)

I’m assuming we will not add configuration options for it in config.toml but it should still be a configuration option to have it enabled.

Valid point. I think, for now, if compile_sass is off, the CSS files remain untouched. It would make sense to use Lightning CSS on those, too, and have a separate config setting, like compile_css or smth…

10

Yeah we can bikeshed the name to make sense and be better than css_prefix_vendor_and_minify = true. Maybe minify should be a separate option. Eg css_prefix_vendor and minify_css being 2 different options

11

I’d propose the following new configuration parameters:

  • transpile_css — when set to “true”, the CSS files will be transformed using Lightning CSS. This allows you to use modern CSS features and future syntax in older browsers
    • transpile_css_target — browser versions to compile CSS for, as a valid Browserslist string
      • (although we can just use defaults, which are pretty good)
  • minify_css — when set to “true”, the generated CSS files are minified

Transpiling and minifying can be done separately. Transpilation/prefixing happens at minify() (yes, counter-intuitive, but this one refers to optimization of queries), while minification happens at to_css()