Tests fail when using es module dependencies

[Pumpuli]

Is this a bug report?

Yes

Can you also reproduce the problem with npm 4.x?

N/A (but yes)

Which terms did you search for in User Guide?

test, lodash, es module

Environment

1. node -v: v8.4.0
2. npm -v: 5.3.0
3. yarn --version: 0.27.5
4. npm ls react-scripts: 1.0.10
5. Operating system: Windows 10
6. Browser and version: Not relevant

Steps to Reproduce

1. Create a new React App
2. Add dependency that is an ES module, e.g. lodash-es
3. Import something from the dependency in App.js, e.g. import { flatten } from 'lodash-es';
4. Run tests; npm test

Expected Behavior

Test passes.

Actual Behavior

Test fails due to ES module syntax in lodash-es causing a syntax error.

Reproducible Demo

https://github.com/Pumpuli/cra-esdeps/

[Pumpuli]

From what I understand, this happens because Jest doesn't do Babel transforms on any node_modules (as configured here). And because Node doesn't support ES modules yet, it causes syntax error.

Not sure about the fix. The only idea I can come up with is to add popular libraries that are ES modules (are there others apart from lodash-es?) to the regex pattern (maybe like this).

[Timer]

We realize this is sub-optimal, and hope Node adds official support for ES Modules soon. This should make things easier, but not immediately.

The most appropriate answer I can give you currently is to not use lodash-es; packages which are published and are expected to work in a Node environment must be shipped in commonjs.
The usage of ES Modules is often enchanting because it promises to trim bundle sizes, but it hardly happens in practice (this is changing in the future; current static analysis limitations).

You'd be better off requiring just the bits you need [from lodash].

In the current state of the ecosystem, Node and webpack considered, packages should be shipped as commonjs, with their commonjs entry point specified in the main of package.json.

For packages who wish to ship a ES Modules build of their module, they should ship them in addition to their commonjs source files, under the module field in package.json (not as a separate package, like lodash-es). Note that these sources must be compiled, meaning they should not use any ES6+ syntax.

In the future, packages may be able to define an esnext field in package.json which says "compile me", so that package authors may ship an uncompiled version of their package (and with modules, basically anything stage 3+).

[dennisat]

We realize this is sub-optimal, and hope Node adds official support for ES Modules soon. This should make things easier, but not immediately.

The most appropriate answer I can give you currently is to not use lodash-es; packages which are published and are expected to work in a Node environment must be shipped in commonjs.
The usage of ES Modules is often enchanting because it promises to trim bundle sizes, but it hardly happens in practice (this is changing in the future; current static analysis limitations).

You'd be better off requiring just the bits you need [from lodash].

In the current state of the ecosystem, Node and webpack considered, packages should be shipped as commonjs, with their commonjs entry point specified in the main of package.json.

For packages who wish to ship a ES Modules build of their module, they should ship them in addition to their commonjs source files, under the module field in package.json (not as a separate package, like lodash-es). Note that these sources must be compiled, meaning they should not use any ES6+ syntax.

In the future, packages may be able to define an esnext field in package.json which says "compile me", so that package authors may ship an uncompiled version of their package (and with modules, basically anything stage 3+).

Thanks @Timer
I would like to add that the correct json property for the es6 dist is the esnext, not the module