Do not throw errors when transforming excluded files

[sthzg]

Thanks for your work on both of the great react-css-modules packages. I want to clarify if a behavior that we experience is expected or open to modification (or of course to be solved by other means).

I am excluding node_modules via the exclude option, which is respected in ImportDeclaration(...), but not in JSXElement(...). The latter will eventually make assertions on excluded files (in our case throwing an error if it finds a styleName prop but no supported imports).

Use case:
This affects us as we are maintaining a non-bundled internal component library that still uses the react-css-modules HOC (as well as a deprecated CSS preprocessor without a postcss syntax) and cannot be immediately refactored to the babel plugin. For the apps that make use of our internal dependency however we want to start using the babel plugin while gradually migrating the other parts over time.

As mentioned above I would like to clarify if opting out in the JSXElement transform if the component's path matches the exclude setting makes sense in your opinion.

// just a quick and dirty check to see if it works in our case
JSXElement(path, stats) {
  const filename = stats.file.opts.filename;

  if (stats.opts.exclude && filename.match(new RegExp(stats.opts.exclude))) {
    return;
  }  
  // ...
}

[sthzg]

I pushed #215 for discussion if the approach of applying the exclude setting not only to the imported style files but also to the location of the JSXElements that request them is okay for the scope of this project.

[sthzg]

hi @gajus - I don't mean to bother but wanted to check if something like #215 or a different implementation to a similar effect would be valuable to the project. As I need something like this I could invest some time either in refinement or working out a different implementation (hints or ideas appreciated). If not it's not a big deal, but it would be great to know as we need to base some decisions on it.

[gajus]

The PR says it is WIP. If it is ready to merge, I am happy to merge it.

[sthzg]

Sounds great - the commit in the PR is currently marked as a feature release - if you are fine with that I will remove the WIP so that it can be merged. Otherwise I can include a BREAKING info or downgrade it to a fix release.

I am not exactly sure about the scope as the original behavior is changed in the following way, which can also be seen as a breaking change.

• old => scanning every file but ignoring imports on style files on excluded files
• new => ignoring also js files that match a path in the exclude pattern.

[gajus]

I think the proposed behaviour is a sane default behaviour. I doubt it would break anything, but seeing this is a change to the way the current logic works, I will release it as a breaking change. Thank you.

[gajus]

🎉 This issue has been resolved in version 5.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀