Using ES6-authored modules with CRA

I’m working on a project that has a dependency on an npm module written in ES6. The module’s package.json includes the following:

  "main": "lib/index.js",
  "module": "src/index.js",

It’s ‘lib’ directory contains transpiled ES5 compatible code; the ‘src’ directory contains the ES6 code ‘lib’ is derived from. This all worked great until I needed to sub-class a class from this module.

CRA’s babel/webpack configuration is picking up the code from ‘src/…’, due to the module entry in the module’s package.json, but is not transpiling it. Therefore babel fails to transpile the sub-class, as it doesn’t support extending native classes.

Solutions/workarounds I’ve found so far include:

• remove the module entry from package.json
  • Pros: module’s transpiled sources are used and everything works
  • Cons: when debugging into the module in devtools I get the transpiled sources, not the original ES6 sources 😕
• edit the react-scripts/config/webpack.config.*.js to include the module in babel transformation
  • Pros: module’s code gets transpiled along with app, everything works, and module’s ES6 source is available untranspiled for debugging
  • Cons: requires unsupported hacking of installed react-scripts files; will break on upgrade
• fork react-scripts to make the above change, use forked version
  • Pros: is a supported way to get a custom config without ejecting
  • Cons: would have to have a react-scripts fork for every project that uses ES6-authored modules 😕

Is there any other approach to getting this working I haven’t found? Could CRA’s build system (or babel configuration) be tweaked to automatically include transpilation of modules like this so things would work out of the box? Any other ideas for how this could be improved?

[gaearon]

I think is not quite correct to use module keyword for the “source code”. The only difference module entry point should have is that it uses ES6 modules instead of CommonJS. That’s why it’s a “module” entry point. This doesn’t mean you should use classes, let/const, arrows, or other ES6 features in the module entry point—unless you’re fine with also using them in your main entry point.

I understand the guidelines are fuzzy on this, but in general I suggest you to limit the difference between main and module to the module system, and not other language features. That’s what it was designed for, and how it is used by bundlers in practice.

Is there any other approach to getting this working I haven’t found? Could CRA’s build system (or babel configuration) be tweaked to automatically include transpilation of modules like this so things would work out of the box?

Yes, but to a limit. Our 2.x alpha versions do compile node_modules by default but only for standard language features. This is essential to avoid fragmenting the ecosystem by tying npm packages to specific (potentially outdated) build tools. So we’ll compile classes (if you target older browsers) but won’t compile JSX or Flow syntax in node_modules. You can try 2.x alphas here: https://github.com/facebookincubator/create-react-app/issues/3815.

Note we’re also working to improve the workflow for multiple components in a single repository. You might want to track https://github.com/facebookincubator/create-react-app/issues/1333 and https://github.com/facebookincubator/create-react-app/pull/3741 for this. The target is also to implement this in 2.x.

Hope this helps!

[laurie71]

Thanks @gaearon — I’ll definately try react 2. Babel 7 is meant to resolve the extending of native classes restriction, which would fix my original problem. To be clear, the ES6 code in node_modules is fine without transpiling for my project. I didn’t even realize the u transpiled code was what was being used until I needed to subclass something.