This is a minimal reproduction example demonstrating the need for the cssmodules-pure-no-check directive in Next.js projects when using CSS Modules

When migrating from CSS-in-JS solutions to CSS Modules in Next.js, certain global styling patterns become difficult to implement due to CSS Modules mode

Although this happens only in edge cases, it would be helpful to bypass the default linting behaviour in these cases

1. Clone this repository
2. Install dependencies:

   npm install

3. Run the development server:

   npm run dev

4. Open http://localhost:3000 in your browser
5. Click the view transition link
6. Observe that the global styling features don't work as expected:

CSS Modules in Next.js currently uses older versions of:

• postcss-modules-local-by-default (< v4.2.0)
• lightningcss (< v1.29.3)

These older versions don't support the cssmodules-pure-no-check directive, which would allow developers to mark specific CSS rules as global, bypassing the default CSS Modules scoping.

Next.js should upgrade its dependencies to support the cssmodules-pure-no-check directive:

// package.json
{
  "dependencies": {
-   "postcss-modules-local-by-default": "4.0.0",
+   "postcss-modules-local-by-default": "4.2.0",
-   "lightningcss": "1.22.0",
+   "lightningcss": "1.29.3"
  }
}

This would allow developers to use the cssmodules-pure-no-check directive in their CSS Modules files:

/* Local component styles */
.myComponent {
  color: blue;
}

/* Global styles that need to bypass CSS Modules scoping */
/* cssmodules-pure-no-check */
:root {
  --global-variable: #333;
}

This pattern mirrors established escape hatches in other tools:

• @ts-nocheck in TypeScript
• /* eslint-disable */ in ESLint
• // @ts-ignore for specific lines in TypeScript

The cssmodules-pure-no-check directive provides a similar escape hatch for CSS Modules when global styling is legitimately needed.