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.

[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.

[sdavids]

I got it finally working with:

import browserslist from 'browserslist';
import browserslistToEsbuild from 'browserslist-to-esbuild';
import { browserslistToTargets } from 'lightningcss';
import { defineConfig } from 'vite';

const bl = browserslist();

export default defineConfig({
  build: {
    cssMinify: 'lightningcss',
    target: browserslistToEsbuild(bl),
  },
  css: {
    transformer: 'lightningcss',
    lightningcss: {
      targets: browserslistToTargets(bl),
    },
  },
});

[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]

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.

[niksy]

What is the status on using LightningCSS in combination with Sass (and other pre-processors)? Is there a list of known issues we can focus on so we get feature parity with PostCSS?

[mayank99]

Looks like preprocessor support was added in #19071 and released in 6.3.0.

From PR description:

still needs some polishing and some minor bug fixes / features in lightningcss for some edge cases, but it's mostly working

after this PR landed, we should be able to graduate transformer: 'lightningcss' from experimental

[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)

[sapphi-red]

Made PR: #19001

[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.

[seanperez-xyz]

I'm a bit late to the party. But I'm actually in a confused state here. @danieltroger I see that your using ?inline, which I am assuming is a css module, I am using qwik which uses vite, followed all the vite config details from lightningcss docs. I see in the docs of lightningcss, that there is an option that needs to be turned on for cssModules:true. Did you have to enable this with your framework and/or within the vite config?

For example qwik vite automatically has the css module support to import styles from myCompStyle.css?inline into the components and handles that differently from the global.css as that is imported into the root.tsx file with import global.css, this is where I'm confused if the current frameworks vite plugin and/or the vite default, are doing this do we need to re declare that for lightningcss config ,or just expect it to work as is?

[sdavids]

Suggestions:

• support the combination of vite and browserslist (and lightningcss) out of the box with something like:

export default defineConfig({
  build: {
    useBrowsersList: true, //< this would set build.target and css.lightningcss.targets if transformer = 'lightningcss'
  },
});

• add a snippet to the docs on how to use the combination of vite, lightningcss, and browserslist:

import browserslist from 'browserslist';
import browserslistToEsbuild from 'browserslist-to-esbuild';
import { browserslistToTargets } from 'lightningcss';
import { defineConfig } from 'vite';

const bl = browserslist();

export default defineConfig({
  build: {
    cssMinify: 'lightningcss',
    target: browserslistToEsbuild(bl),
  },
  css: {
    transformer: 'lightningcss',
    lightningcss: {
      targets: browserslistToTargets(bl),
    },
  },
});

• browserslistToEsbuild renamed to browserslistToBuildTarget as part of vite instead of relying on an external dependency

[justinbeaty]

I'm using vite 8 beta and want to use lightningcss for both transform and minify, but it causes a custom lightningcss visitor plugin to run twice. While for my specific plugin it doesn't cause a problem, I could see it causing problems for more specific transform plugins. As well as it being slightly slower (even though lightning css is fast).

The root cause is that config.css.lightningcss is spread into both lightningcss calls in plugins/css.ts.

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

Lines 2193 to 2196 in 1804417

	try {
	const { code, warnings } = (await importLightningCSS()).transform({
	...config.css.lightningcss,
	targets: convertTargets(config.build.cssTarget),

Could we either have transform and minify overrides, i.e.:

{
    ...config.css.lightningcss,
    ...config.css.transform?.lightningcss,
    // ...
}

// and 

{
    ...config.css.lightningcss,
    ...config.css.minify?.lightningcss,
    // ...
}

Or perhaps allow config.css.lightningcss to be a function? i.e.:

  css: {
    transformer: 'lightningcss',
    lightningcss: (mode: 'transform' | 'minify') => {
      return { ... }
    },
  },