Exciting release!Introducing "safe npm". Learn more
Log inDemoInstall


Package Overview
File Explorer

Advanced tools


A CSS parser, transformer, and minifier written in Rust


Version published
Weekly downloads
decreased by-13.04%

Weekly downloads




This release includes several features and improvements for the custom visitor API, including support for defining how to parse custom at rules. In addition, lots of bug fixes are included for auto prefixing, selector downleveling, and more.

Custom at-rules

When Lightning CSS does not know how to parse an unknown at rule, it stores the prelude and body as a list of raw tokens. Without a definition for how a rule should be parsed, Lighting CSS doesn't know how to interpret it. Tokens are fine for simple use cases, but if you are building a custom visitor plugin that processes a custom at-rule, and want it to integrate with the rest of CSS, it is useful to define how the rule should be parsed and interpreted. In this release, a new customAtRules option has been added to the API to enable just that.

For example, here is how you could define an @mixin rule which expects a custom identifier as its prelude, and a style-block as its body. This allows nesting declarations and rules just like other at-rules like @media and @supports.

{ customAtRules: { mixin: { prelude: '<custom-ident>', body: 'style-block' } } }

With that, you can parse code like this:

@mixin foo { color: red; &.bar { color: green; } }

Lightning CSS also validates the code and will emit syntax errors when it doesn't conform to the syntax definition. Another nice part is that we use this definition to automatically infer the TypeScript types for these rules when used in custom visitors.

<img src="https://user-images.githubusercontent.com/19409/218497162-a0acfb24-6351-4c46-8ff7-1bd20e3c6ff6.jpeg" height="400">

Check out the documentation to learn more!


  • Implement support for parsing custom at rules in JS bindings (#395)
  • Support raw property on returned declarations in visitors (#385)
  • Support raw values in visitors that return tokens (f9ed30f9ed8399d1599a9724eb55ce7e0c0ee8ba)
  • Make more AST properties optional in visitor return types (3fc05a9af629b69b72eaf5371891961d93450a1d)
  • Add substitute_variables function to UnparsedProperty in the Rust API (#388)
  • Add Implement Property::set_prefix function (a19228dcda0cc0fa6a98f1c9ab19829d9f8c0584)
  • Merge non-adjacent @layer rules (6419d542bad89b4f64dcf5a2f481a4e6b6d8a7a9)
  • Short-circuit on error in Rust visitor API (#406)
  • Support nesting selector at the root, which is transformed to :scope (44434116f4a0f0182a041971028b6cc729ecadc4)


  • fix: <layer-name> should be escaped (#383)
  • WASM: Only use import.meta.url in fallback scenario (#410)
  • Publish docs for optional features on docs.rs (#407)
  • Support node in wasm package (#387)
  • Fix parsing oblique angles in font-style descriptor (0e84e8e82a84c7b299b929f805d52f88bb4305ef)
  • Update autoprefixer data for text-decoration (a58ea6fa31539efd31d963d2c896d3eb9706e38e)
  • Bump mdn compat data (59cbc023691b4eca1d1fa3e53cc797e148336a37)
  • Fix downleveling selectors in :is, :where, and :has (31fc453d9031f5fb4592ee92cd430e31c82697d5)
  • Fix serializing :host and ::slotted selectors (482fc40358819c3e006f8c20ffb7e4bce2e1fd05)
  • Copy license into all npm packages (856d460b91b333ccc08fa4ba9d5131d637fb0f5a)
  • Improve deserialization error messages for custom visitors (331c8a9acaa16b1e1b6053fef29c96858d19a03e)
  • Fix cue-region-function ast types (6a53944ec91e924ee97c82b37d539857b049e32a)
  • Fix serializing currentColor (fcf41273a806e9c9245f7ce87c87d69b14a98603)
  • Use unpkg module option in docs for wasm (f394b50f9f772c8d044cf0208f50a701f32a4025)



⚡️ Lightning CSS

An extremely fast CSS parser, transformer, and minifier written in Rust. Use it with Parcel, as a standalone library or CLI, or via a plugin with any other tool.

performance and build size charts performance and build size charts


  • Extremely fast – Parsing and minifying large files is completed in milliseconds, often with significantly smaller output than other tools. See benchmarks below.
  • Typed property values – many other CSS parsers treat property values as an untyped series of tokens. This means that each transformer that wants to do something with these values must interpret them itself, leading to duplicate work and inconsistencies. Lightning CSS parses all values using the grammar from the CSS specification, and exposes a specific value type for each property.
  • Browser-grade parser – Lightning CSS is built on the cssparser and selectors crates created by Mozilla and used by Firefox and Servo. These provide a solid general purpose CSS-parsing foundation on top of which Lightning CSS implements support for all specific CSS rules and properties.
  • Minification – One of the main purposes of Lightning CSS is to minify CSS to make it smaller. This includes many optimizations including:
    • Combining longhand properties into shorthands where possible.
    • Merging adjacent rules with the same selectors or declarations when it is safe to do so.
    • Combining CSS transforms into a single matrix or vice versa when smaller.
    • Removing vendor prefixes that are not needed, based on the provided browser targets.
    • Reducing calc() expressions where possible.
    • Converting colors to shorter hex notation where possible.
    • Minifying gradients.
    • Minifying CSS grid templates.
    • Normalizing property value order.
    • Removing default property sub-values which will be inferred by browsers.
    • Many micro-optimizations, e.g. converting to shorter units, removing unnecessary quotation marks, etc.
  • Vendor prefixing – Lightning CSS accepts a list of browser targets, and automatically adds (and removes) vendor prefixes.
  • Browserslist configuration – Lightning CSS supports opt-in browserslist configuration discovery to resolve browser targets and integrate with your existing tools and config setup.
  • Syntax lowering – Lightning CSS parses modern CSS syntax, and generates more compatible output where needed, based on browser targets.
    • CSS Nesting (draft spec)
    • Custom media queries (draft spec)
    • Logical properties
    • Color Level 5
      • color-mix() function
      • Relative color syntax, e.g. lab(from purple calc(l * .8) a b)
    • Color Level 4
      • lab(), lch(), oklab(), and oklch() colors
      • color() function supporting predefined color spaces such as display-p3 and xyz
      • Space separated components in rgb and hsl functions
      • Hex with alpha syntax
      • hwb() color syntax
      • Percent syntax for opacity
      • #rgba and #rrggbbaa hex colors
    • Selectors
      • :not with multiple arguments
      • :lang with multiple arguments
      • :dir
      • :is
    • Double position gradient stops (e.g. red 40% 80%)
    • clamp(), round(), rem(), and mod() math functions
    • Alignment shorthands (e.g. place-items)
    • Two-value overflow shorthand
    • Media query range syntax (e.g. @media (width <= 100px) or @media (100px < width < 500px))
    • Multi-value display property (e.g. inline flex)
    • system-ui font family fallbacks
  • CSS modules – Lightning CSS supports compiling a subset of CSS modules features.
    • Locally scoped class and id selectors
    • Locally scoped custom identifiers, e.g. @keyframes names, grid lines/areas, @counter-style names, etc.
    • Opt-in support for locally scoped CSS variables and other dashed identifiers.
    • :local() and :global() selectors
    • The composes property
  • Custom transforms – The Lightning CSS visitor API can be used to implement custom transform plugins.


Lightning CSS can be used from Parcel, as a standalone library from JavaScript or Rust, using a standalone CLI, or wrapped as a plugin within any other tool. See the Lightning CSS website for documentation.


performance and build size charts performance and build size charts $ node bench.js bootstrap-4.css cssnano: 544.809ms 159636 bytes esbuild: 17.199ms 160332 bytes lightningcss: 4.16ms 143091 bytes $ node bench.js animate.css cssnano: 283.105ms 71723 bytes esbuild: 11.858ms 72183 bytes lightningcss: 1.973ms 23666 bytes $ node bench.js tailwind.css cssnano: 2.198s 1925626 bytes esbuild: 107.668ms 1961642 bytes lightningcss: 43.368ms 1824130 bytes

For more benchmarks comparing more tools and input, see here. Note that some of the tools shown perform unsafe optimizations that may change the behavior of the original CSS in favor of smaller file size. Lightning CSS does not do this – the output CSS should always behave identically to the input. Keep this in mind when comparing file sizes between tools.


Last updated on 13 Feb 2023

Did you know?

Socket installs a Github app to automatically flag issues on every pull request and report the health of your dependencies. Find out what is inside your node modules and prevent malicious activity before you update the dependencies.

Install Socket
support@socket.devSocket SOC 2 Logo


  • Package Issues
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.

  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc