Skip to content

Conversation

@jantimon
Copy link
Contributor

This PR adds support for the /* cssmodules-pure-no-check */ comment which allows users to disable the pure CSS modules check for the entire file (similar to // @ts-nocheck)

The feature is a port from postcss

Details

  • Parsing Change: Detects the /* cssmodules-pure-no-check */ comment at the beginning of the CSS file and sets pure to false in css_modules options.
  • Test Cases: Added tests to verify the functionality, ensuring the comment works as expected even with preceding comments.

Solves #889

@devongovett devongovett merged commit 3122b65 into parcel-bundler:master Mar 14, 2025
@jantimon jantimon deleted the feature/cssmodules-pure-no-check branch March 14, 2025 17:47
joshuadavidthomas pushed a commit to joshuadavidthomas/lightningcss that referenced this pull request Mar 17, 2025
joshuadavidthomas pushed a commit to joshuadavidthomas/lightningcss that referenced this pull request Mar 17, 2025
samcx added a commit to vercel/next.js that referenced this pull request Apr 2, 2025
… like View Transitions (#77321)

## What?

This PR adds support for `cssmodules-pure-no-check` in CSS Modules by
upgrading `postcss-modules-local-by-default` from 4.0.4 to 4.2.0
(`cssmodules-pure-no-check` was also recently [merged into LightningCSS
1.29.3](parcel-bundler/lightningcss#898))

## Why?
Global CSS selectors like View Transitions API require global scope to
work properly. Currently, there's no clean way to use these selectors
with CSS Modules in Next.js, which causes issues when:
1. Using the View Transitions API
2. Migrating from css-in-js libraries like styled-components to React
Server Components with CSS Modules

## How?
- Upgrades `postcss-modules-local-by-default` to 4.2.0
- Adds support for the `/* cssmodules-pure-no-check */` comment pattern
in CSS files which disables CSS Modules localization for that file
- This mirrors established escape hatches in other tools (`@ts-nocheck`,
`/* eslint-disable */`)
- Added tests (similar to one @samcx wrote previously) to ensure
functionality works correctly

The approach was previously approved by @samcx in issue #77232, who
mentioned that LightningCSS was already bumped, but we needed to bump
the PostCSS side

Fixes #77232

---------

Co-authored-by: Sam Ko <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants