next.js

6ac4fd6e - add support for css-in-js ressource mapping in experimental lightningcss-loader (#64551)

add support for css-in-js ressource mapping in experimental lightningcss-loader (#64551) ## Summary This PR proposes removing the redundant regular expression check (`/\.module\.\w+$/i`) from the `lightningcss-loader` configuration. The removal aims to resolve conflicts with css-in-js modules when using inline `matchResource` mapping: https://github.com/jantimon/next-yak ## Background The current webpack setup within `next.js` uses specific regular expressions to differentiate between global styles and module styles for both CSS and Sass files. Definition: https://github.com/vercel/next.js/blob/2e44b49af397d9417063024c3e21a887eb8f17a9/packages/next/src/build/webpack/config/blocks/css/index.ts#L21-L27 Usage: https://github.com/vercel/next.js/blob/2e44b49af397d9417063024c3e21a887eb8f17a9/packages/next/src/build/webpack/config/blocks/css/index.ts#L290-L295 https://github.com/vercel/next.js/blob/2e44b49af397d9417063024c3e21a887eb8f17a9/packages/next/src/build/webpack/config/blocks/css/index.ts#L463-L470 In addition the experimental `lightningcss-loader` introduces another regex (`/\.module\.\w+$/i`) for the very same thing directly for the file name. Unfortunately this **duplicate check** introduces a problem for loaders that use an [Inline `matchResource`] mapping to change the resource name. (e.g. to extract css from a ts file) ## Proposed Change This PR removes the `/\.module\.\w+$/i` regex check from the `lightningcss-loader` and relies on the existing regex patterns for CSS and Sass from