cssmodules-pure-no-check feature

[jantimon]

hi @devongovett

would you be open to port the cssmodules-pure-no-check feature from postcss to lightningcss?

The feature is a limited opt-out for the cssModules: { pure: true } linting rule similar to @ts-ignore or @ts-nocheck or eslint-disable for edge cases in large projects where lightningcss is configured globally

For example:

/** cssmodules-pure-no-check */

:global(#stripe-modal-backdrop) {
  background: rgba(0, 0, 0, 0.5);
}

In postcss the /** cssmodules-pure-no-check */ disables the linting rule for the entire file.

If you are okay with porting the feature I would love to start working on a PR

[jantimon]

I went ahead and implemented this in the PR #898 to give you a better idea

Its just a minimal change but would be really helpful for projects transitioning to pure CSS modules

Please take a look when you have a chance

[uni0ue]

Hi there! Just ran into the same issue while migrating to lightning-css - the pure mode is great but we need some exceptions for third-party stuff. This PR looks like exactly what we need. Any chance of getting some eyes on this when possible?

[devongovett]

Seems like you should just not pass pure: true to lightningcss in the first place if you don't want it enabled?

[Mad-Kat]

You are right pure: true seems like the obvious solution. However for codebases relying on meta frameworks that wrap lightning-css (looking at you next.js) the problem becomes more complicated.

Imho it's similar to how we handle other linting tools - instead of disabling ESLint or TypeScript completely, we use selective opt-outs like eslint-disable or @ts-ignore for edge cases. This allows us to keep the linting active for 90% of the codebase while explicitly opting out only for edge cases.

For example LightningCss uses #![allow(clippy::not_unsafe_ptr_arg_deref)] instead of disabling not_unsafe_ptr_arg_deref for the entire repository

Many developers use Lightning CSS through frameworks that apply these settings globally and don't expose configuration options. For example, when a meta-framework already configures Lightning CSS with pure: true, developers may not have direct control to turn it off without significantly complicating their setup.

This feature would be very helpful for large projects coming from styled-components and want to switch to pure CSS modules for better performance.

[jantimon]

Exactly - for example Next.js sets pure: true by default and does not allow to change it

[devongovett]

Hmm, I kinda regret adding the pure feature now. Lightning CSS is not intended to be a linter, so this feature really seems better for a different tool to handle. 🤔

[Mad-Kat]

I think this is exactly the problem. The pure check can help to say that the CSS imports can be freely moved around as they're always independent
But to guarantee that, we need to check/lint the written CSS rules.

[jantimon]

Actually pure does not make it independent (especially specificity is still a challenge) - pure only guarantees unique css class names

Lightning CSS is not intended to be a linter

Totally agree - Linting is always opinionated

For postcss it already felt hacky but at least it was a dedicated plugin and not part of the core

With the Lightning CSS monolith architecture every opinionated linting idea would have to be added directly to the main repository

How can we move on from here?

Will you remove the linting entirely from lightingcss soon?

If not could we merge the PR for now?

[devongovett]

Well, there are other CSS linters that could do this too. stylelint, biome, etc.

Will you remove the linting entirely from lightingcss soon?

Probably can't now, that would be a breaking change. It was added by the Next.js team in #796 (@kdy1 @timneutkens). Not sure if they had a request on their side.

Given that, I guess we can add support for the comment. But I'd like to avoid adding further linting features in the future.