Stabilizing Lightning CSS

[patak-dev]

Lightning CSS support

• Added as experimental in [email protected]
• Original PR by @ArnaudBarre
• Docs
• API to stabilize
  • css.transformer
  • css.lightningcss
  • build.cssMinify

We're creating this discussion to gather feedback about this feature, so we can later use it while moving it out of experimental.

[Marabyte]

I have a PR here attempting to fix an issue when using LightningCSS and html-proxy

[susickypavel]

I've struggled with configuring the targets when minifying using lightningcss. Firstly, I went for configuring the css.lightningcss.targets, but that didn't do anything. Then I searched through the source code and found out that when minifying, I need to specify the build.target or build.cssTarget to make it work.

[fvsch]

I’m struggling currently to configure the targets. In particular, Lightning CSS always transpiles CSS Logical Properties to extremely long selector lists looking like :not(:lang(a)):not(:lang(b)):not(:lang(c))….

Lightning CSS itself doesn't show this behavior in its online playground with no targets specified or with sufficiently recent targets.

I tried setting no targets, setting either build.cssTarget or css.lightningcss.targets, setting both, also setting css.lightningcss.exclude, and more.

As it stands, it looks like the type for css.lightningcss is a lie, and things like css.lightningcss.targets and css.lightningcss.exclude are either ignored or overwritten by Vite.

[susickypavel]

I managed to make it work by converting browserslist query to esbuild version using browserslist-to-esbuild package and setting it in build.target.

import browserslistToEsbuild from "browserslist-to-esbuild";

import { browserslist } from "./package.json";

build: {
  target: browserslistToEsbuild(browserslist),
}

// package.json
{
  "browserslist": [
    "defaults and supports es6-module"
  ]
}

if it helps.

[fvsch]

It does. Looks like the issue is that, in the absence of documentation or examples for what targets are supposed to look like, I ended up in the ESBuild docs and ended up defining targets as build.cssTarget: 'chrome115,firefox115,safari16' when I actually needed an array of strings.

It also looks like targets may get merged when defined like this:

export default {
  build: {
    target: 'es2018'
  },
  css: {
    transformer: 'lightningcss',
    lightningcss: {
      targets: { chrome: 115, firefox: 115, safari: 16 }
    }
  }
}

I suspect the es2018 target gets converted to browser versions, including versions for Edge or safari_ios or some other browsers, and merged with the values in css.lightningcss.targets.

Kind of a footgun.

[fvsch]

Hmm, tried a few more combinations and it looks like the only thing that works reliably is having a build.target value that lists specific browser versions, such as target: ['chrome115', 'safari16'].

If you:

• don't define build.target
• or define build.target as something that will get translated to a list of browsers that is slightly too wide for the Lightning CSS features you want to use

then this implicit or explicit build.target gets preference, or is merged with the css.lightningcss.targets values (not sure). The build.cssTarget value seems ignored. That looks like a bug.

So it looks like there might be two bugs:

1. Lightning CSS targets are not derived from build.cssTarget
2. Lightning CSS features cannot be configured with css.lightningcss.exclude (it's either ignored or overwritten by the targets; and according to LightningCSS docs it should take precedence over targets)

[susickypavel]

It's been two months since I looked into this, but when I went through the source code of lightningcss implementation in Vite it seemed very roughly implemented. If I remember correctly the cssTarget is indeed totally unused and has no effect whatsoever.

[mayank99]

imo lightningcss should not be stabilized until there is support for pre-processors.

• there is a large number of sass and tailwind users that expect it to work smoothly in vite.
• having some features/syntaxes officially supported that suddenly stop working because the css transformer was changed is a very confusing experience.
• there are tons of postcss plugins that will never have a lightningcss equivalent.
• the third-party lightningcss plugin already works fine with postcss/sass, so it's strange that the official core plugin doesn't.
• when not opting into postcss/sass features, there is no performance penalty hence no downside.

[mayank99]

speed is not the only reason for using lightningcss though; as Devon mentioned, there are some very nice features in lightningcss. and yes, it would also be good to have benchmarks instead of vague claims about speed gains not being enough.

i also do not get the point about tailwind being possible to use without postcss. does that mean vite will officially support tailwind without postcss? sass has always been usable without postcss, and there is now even a native option (sass-embedded) that improves performance.

in all cases, sass/tailwind/postcss produce a vanilla css file that lightningcss understands and can do postprocessing on, so it feels like something that should be supported.

i'm really trying to understand the argument against this, and the only reasonable one i can see so far is that it might result in some bugs. but that's exactly why i think it should stay experimental.

[ArnaudBarre]

I totally agree that lightningcss has great features. My question is what's the need for pre-processor on top of lightningcss?

Using Tailwind without PostCSS is not something available yet, it needs some work from the Tailwind team: https://youtu.be/CLkxRnRQtDE?t=3018

The main argument for me is that pre-processors where added to fix missing features of CSS (variables, nesting). Now that this is supported, I think we should go back to pure CSS with some speedy transformation done by lightningcss.

[mayank99]

Pre-processors and post-processors are different things. The line is a bit blurry, but I see pre-processors as a different syntax for writing CSS, while post-processors are more like polyfills/extra features added to vanilla CSS syntax (usually; some postcss plugins can of course go wild). The strength of using a pre-processor is that it is for static things and compiles away. I agree CSS has come a long way, but it's still missing very important features like static variables, loops, conditions, mixins, functions.

You may personally feel it is unnecessary, but there are many users who will feel alienated if Vite takes the strong stance of not supporting Sass in future apis. You can see the number of reactions on this comment: #12807 (comment)

[ArnaudBarre]

Thanks for the answer. I agree that static variable is something missing. For the rest, I personally feel that's the root to bloated CSS a la Bootstrap and that Tailwind JIT (from WindiCSS at its origins) is way better for dev perf and DX than generating a lot of CSS and then doing some tree-shaking.

But still, I can get that not everyone is on the Tailwind/UnoCSS train, so I would not be against improving support for this, but that will not be my priority in the coming months

[lamka02sk]

I have to agree with @mayank99 on this one. We use Sass in every Vite installation and there are currently many benefits over PostCSS, mainly easier setup, easier onboarding and better syntax (for example CSS variables are pretty ugly tbh). Yes, we could do pretty much the same by installing 20 PostCSS plugins, but that is going to be a pain to maintain and developers then tend to not use certain features, because they are not sure if it is supported or not - or worse, they install more plugins to do the same thing.
If you ever decide to make lightningcss the default without pre-processor support, you should also keep the support for PostCSS and make it obvious in the docs.

[mayank99]

also doesn't currently work in stackblitz.

there is a lightningncss-wasm package that works in the browser, but it doesn't support the bundleAsync method that vite uses. see parcel-bundler/lightningcss#277

vite/packages/vite/src/node/plugins/css.ts

Lines 2177 to 2179 in df77991

	: await (
	await importLightningCSS()
	).bundleAsync({

it might make sense to fallback to postcss in the browser.

[AlexErrant]

Should work on Stackblitz as of https://github.com/parcel-bundler/lightningcss/releases/tag/v1.21.6

[mayank99]

no it won't. that release only adds stackblitz support for the transform api. bundle still doesn't work.

[AlexErrant]

Forgive my ignorance - are people really using Stackblitz to bundle apps?

[mayank99]

it's not about bundling apps (although i do expect vite build to work in stackblitz). as i mentioned in my first comment, vite uses the bundle api from lightningcss, and this api is not present in lightningcss-wasm. see https://stackblitz.com/edit/vitejs-vite-byy6ux?file=vite.config.js

[devongovett]

As of Lightning CSS v1.21.8, bundleAsync now works in the wasm build too. See parcel-bundler/lightningcss#583 for details on how I made this work if you're curious. Here's a demo of Vite with Lightning CSS working in Stackblitz: https://stackblitz.com/edit/vitejs-vite-ci74wh?file=vite.config.js

[sapphi-red]

I think this needs to be fixed before stabilizing: #13776 (comment)

[bluwy]

There has also been CI fails because of lightningcss it seems: https://github.com/vitejs/vite/actions/runs/6183034651/job/16783939656#step:13:88

Seeing ELIFECYCLE  Command failed with exit code 3221225477. always after the playground/css-lightningcss-proxy/__tests__/css-lightningcss-proxy.spec.ts when it happens. Not always reproducible though.

[Marabyte]

I don't think visitor is working.
Here's a small stackblitz reproducing the problem: https://stackblitz.com/edit/vitejs-vite-due6fx?file=vite.config.js

Am I missing something?

[ArnaudBarre]

It works if you're using Vite 5.0.0-beta.2 (the PR was merged after the latest stable)

[Demir-Utku]

What are your thoughts about using Lightning CSS in production? Is it stable and clear enough to use?

[ArnaudBarre]

I think it's the default on Parcel and probably being used at Adobe in production

[Demir-Utku]

Thank you for the answer. Do you know how Adobe uses the Lightning CSS, under a bundler or a customized way?

[ArnaudBarre]

@devongovett probably can tell

[danieltroger]

We've been using it in prod where I work (through parcel) for quite some time and we usually break things if they aren't stable, so from my experience yes.

[danieltroger]

Alright I never actually got this feature working with vite but here's my feedback:

1. I also want to use lightningcss with sass, so lightningcss should minify sass' output
2. When importing a style file like this: import styling from "./style.scss?inline"; neither the current nor lightningcss minification gets applied on the style. I don't know if this is a bug in vite <5.0.0 because I can't update right now and I'll just find a workaround, but good if you can test if this actually works in your currently supported usecases on the latest version

[solution-loisir]

To have static variables work inside of @media queries is one use case that I think of and that could make me want to use sass alongside of lightning CSS these days. Is this possible to achieve with the visitor API somehow? Is there a list of lightning CSS plugins available anywhere? I've searched, but couldn't find anything.