Improving lightningcss maintenance - please help!

[devongovett]

Lightning CSS usage has skyrocketed in the last year. It is now used in almost every major modern build tool, including Next.js, Vite, Rspack, Tailwind, Parcel, Bun (a port), etc. npm downloads have increased to over 70 million per week, and that does not include Next.js or Rspack, which embed the Rust crate directly. So the real number is probably over 100 million.

This is really incredible, but to be honest, I could use some help with maintenance. I appreciate sponsorships, but unfortunately this does not magically create more time for me to work on it. CSS is evolving very quickly and it's difficult to keep up with all the new features as a solo dev. I'm sorry if my slowness has affected you.

Now that Lightning CSS is a core ecosystem dependency, I need to find a way to improve this. I am reaching out to each of the major tools using Lightning CSS to bring on additional maintainers. Hopefully we can get a good core team established and speed up the process a bit.

If you're interested in helping, please reach out (here or on Discord in the lightningcss channel). I'll be inviting people how have submitted a few good pull requests and generally show an interest in helping on a somewhat regular basis. We have some funds in Parcel's OpenCollective that we can also distribute at my discretion.

What needs to be done

An incomplete list of the main work streams:

• Keep up with the latest CSS specs – As you can probably tell from the issues, CSS is evolving very quickly, with new properties and rules being added very regularly. Due to Lightning CSS's architecture which fully parses all syntax, we need to implement parsing and serialization for each of these. This is both an advantage and a disadvantage.
• Improve test coverage – The current tests are manually written, which is great, but it would be amazing if we could automatically run a subset of the web platform tests against Lightning CSS. This would help us detect edge cases in the existing implementation, as well as missing features.
• Automate detection of new CSS features – Going along with both items above, it would be great if we had a set of scripts to parse the CSS specifications and determine which properties/rules we are missing implementations for. It's currently a manual process to detect when spec changes occur and it would be great if we at least knew how up to date we are.
• Automate performance and minification size regression checking
• Automate browser support data updating – Currently I run the scripts/build-prefixes.js script before each release to update the browser support data. Would be great if this was automated.
• Automate updating the TypeScript types – scripts/build-ast.js builds ast.d.ts from the Rust source. This currently must be done manually before each release.
• Keep dependencies up to date – The cssparser and selectors crates from Servo need updating periodically.
• Automate releases – Currently I do releases manually. Would be nice to be able to release fixes more quickly when they are merged. This probably means automating release notes and GitHub releases, and some way to detect or mark PRs as minor or patch. We may want to batch multiple commits/features together so this will need some discussion.
• Triage and fix bugs – Obviously. But if bugs are reported to upstream frameworks, PRs would be great. And reviewing PRs is also appreciated.

Project philosophy

A few things off the top of my head for maintainers to keep in mind.

• Fully parse all syntax – this is key to Lightning CSS's performance, minification, and correctness. Even though it is more work than storing raw tokens in the AST like other CSS parsers do, it is worth it.
• No non-standard features – CSS is a very flexible language and many tools have extended it with additional rules/properties/syntax. Non-standard rules and properties can be passed through in the errorRecovery mode, as long as they are valid CSS syntax. Other syntax extensions should not be supported because this greatly complicates the tokenizer/parser. These should be processed by external tools before the output is passed to Lightning CSS.
• Limit hacks for very old browsers – Generally target browsers that people actually use. Adding extra code to work around bugs in really old browsers that aren't being used is not worth it. The CSS specification is the source of truth – implementation bugs are not.
• Put experimental/draft features behind flags – Draft syntax (e.g. only supported in Chrome) is subject to change, especially if other browsers have not yet committed to implement it. We don't want to be locked into supporting features that change later and result in breaking changes. Put these behind draft feature flags that users can choose to enable at their own risk.
• Be careful when using AI – Understanding the code you're submitting is very important. Lightning CSS is used by millions of developers, so we have a responsibility to retain the correctness, efficiency, and maintainability of the code, avoid breaking changes, etc.

[Marukome0743]

Hi @devongovett,

Thank you for opening this discussion. I'd love to help with Lightning CSS maintenance.

I've landed one PR on this repo so far (#929, shipped in v1.29.2), and I've been actively contributing across the broader frontend toolchain ecosystem — including Bun, which you mentioned ships a port of Lightning CSS. I'd be glad to bring that focus here on a regular basis.

Areas I'd like to focus on:

• :placeholder-shown and similar selector/prefix coverage
• Automating scripts/build-prefixes.js browser support data updates
• Triaging and fixing CSS spec compatibility bugs
• Reviewing incoming CSS-feature PRs

📋 Background & relevant contributions

• CSS prefix / selector expertise — I authored autoprefixer#1532, which fixed the old -moz- prefix handling for :placeholder-shown. Released and credited in autoprefixer's changelog (10.4.20+), so it now propagates through every downstream tool depending on autoprefixer. Same area as my Lightning CSS PR — I have a solid grasp of historical browser prefix behavior and how it maps onto modern selectors.

• Bun (oven-sh) — Contributor credited in the Bun v1.1.27 release, and authored setup-bun#96 (first contribution there). Bun ships a port of Lightning CSS, so I have context on how the project is consumed downstream.

• Next.js (vercel/next.js) — PR #66737 merged into canary, updating create-next-app template after the Geist/Inter font swap.

• Other merged PRs — Supabase, nginx-proxy, drizzle-orm, and more. Comfortable navigating large codebases, following project conventions, and writing focused PRs that are easy to review.

🎯 Alignment with project philosophy

I align well with the philosophy you outlined — particularly:

• "Fully parse all syntax"
• "CSS spec is the source of truth"
• Being careful with AI-assisted code

I prefer small, well-scoped, understandable changes.

I'll keep submitting PRs to demonstrate the regular involvement you're looking for, and I'm happy to chat further on Discord in the #lightningcss channel. Whatever level of involvement makes sense — occasional contributor, reviewer, or eventually a maintainer — I'm in.

Thanks again for being open about needing help. Lightning CSS is foundational infrastructure now, and I'd be honored to help carry some of the load.

Best,
Marukome0743

[kdy1]

IMHO, I think we need more automations to help contributors contribute with confidence.

In my experience, the automated regression testing was the most important thing. The regression testing need to be stable, and should not require too much time for the contributor side.

I think codspeed is the best (and maybe only) tool for performance part, so I created #1243
I got some help from AI because it's not a part that requires 100% correctness, although I reviewed all codes.

[kdy1]

Regarding the publish automation pipeline, how do you think about using changeset in a customized way, like https://raw.githubusercontent.com/swc-project/swc/68af779eff35120407a7147b3b60700c54db243c/.changeset/rewrite-this-destructuring-defaults.md ?

We can mark a PR as patch or minor and while merging consume all of those files

@devongovett

[IronBlood]

Hi @devongovett half an year ago I opened #1113 trying to migrate from napi-rs v2 to v3. Maybe this can be a start point for "automate updating the TypeScript types"? Originally I wanted to implement the glue layer by reverse engineering from the type definitions, so that later napi-cli can generate the type definitions from the Rust code. But I soon gave up because I was new to both lightningcss and napi-rs. So I focused only on migrating the implementations, leaving type definitions untouched. I had tested on varies platforms with this CI.yml, and noticed some exceptions, for example floating numbers might be slightly different on Windows, wasm32 drops error filename and location.