feat: implement regExp option

[lkmill]

this PR adds a regExp option that is passed to loaderUtils.interpolateName. This option is called localIdentRegExp in webpack.

[lkmill]

@longlho @alexander-akait any chance of getting this considered?

[alexander-akait]

Hello, can you clarify why you need it (example)?

[lkmill]

hey sorry for the quick reply, hope i'm not spamming.

i use it mainly through the localIdentRegExp option from css-loader in projects where the css module files are named *.module.s?css to remove module from the resulting class name. for example i often have:

modules: {
  localIdentName: '[1]_[local]',
  localIdentRegExp: /([^/]*).module.s?css/,
},

this results in names like navigation_base instead of navigation-module_base.

projects with SSR use tools (eg babel-plugin-css-modules-transform) that depend more directly on generic-names and only have generateScopedName exposed. to solve the problem in those cases i create a function

export default function generateScopedName(name, path) {
  const parsed = p.parse(path)
  const filename = parsed.name.replace('.module', '')

  return `${filename}__${name}`
}

which i then use in babel.config.js

plugins: [
  [
    'css-modules-transform',
    {
      generateScopedName,
      extensions: ['.scss'],
      processorOpts: { parser: scssParser },
    },
  ],
],

and in webpack.config.js

modules: {
  getLocalIdent: (loaderContext, _localIdentName, localName) =>
    generateScopedName(localName, loaderContext.resourcePath),
},

it would be nice to be able to use the regex option in both cases and avoid having to create the function to share between the contexts.

[alexander-akait]

I think we don't need it here, I think pre/post processing in css-loader should help here, regexp is limited, with function notation you will have more power and it allows to solve more problems (like this)

[alexander-akait]

So we can add new options beforeGetLocalIdent and afterGetLocalIdent

[lkmill]

I agree function notation is more powerful, but regex is considerably more concise for simple solutions. This PR doesnt really add any logic to this library, it simply exposes an already existing API from loader-utils/lib/interpolateName.js. I also figured there could be some value in having the same functionality in this library as in webpack.config.js.

[alexander-akait]

Can you update docs, otherwise it will be PR only for you and me and nobody will know how to use it 😄

[pstrh]

@alexander-akait @lohfu It would be great if this PR gets merged. I would be willing to update the docs in another PR if there's a chance to get this merged.

[pstrh]

@sapphi-red @madyankin I would like to make you aware of this PR. It would be great if the regExp option would be added subsequently to postcss-modules and Vite. Is there a chance that this gets added? It would allow to interpolate the component name without the -module suffix. I could try to contribute respective PRs to both projects.

Currently if your scss file in Vite is MyComponent.module.scss and generateScopedName: "[name]_[local]__[hash:base64:5]" it resolves to MyComponent-module_LocalName_Hash. With the regExp option it would be possible to get rid of the -module suffix via generateScopedName: "[1]_[local]__[hash:base64:5]" and regExp: /([^/]*).module.s?css/. At the moment we have to implement our own generateScopedName function to achieve this.

[sapphi-red]

@pstrh I think that's possible by using the function type generateScopedName.

[pstrh]

@sapphi-red Thanks for your response. You're right, we could adapt the component name with a custom function. But the problem is that this bloats the vite config. We would also have to reimplement some functionality of interpolateName or add loader-utils as dependency. Something similar was done in Create React App or Next.js. It feels kind of an overhead to reimplement this in several projects. The regExp option looks like a nice shortcut and would only expose existing functionality of interpolateName.