Use lodash-es for ES modules

[corydeppen]

Resolves #1286

[apollo-cla]

	Warnings
⚠️	There are library changes, but not tests. That's OK as long as you're refactoring existing code

Generated by 🚫 dangerJS

[corydeppen]

Sorry for the noise - I mistakenly ran compile instead of test prior to committing so I didn't see the issue until it was too late. It appears the problem is that lodash-es ships ES modules, which aren't transformed by Jest. I'm hoping solution 3 will solve this issue.

[jbaxleyiii]

@corydeppen what is lodash-es?

[jbaxleyiii]

Ah! I see #1286 (comment)

Can you take a look at the CI failure? And add a changelog and I'd love to merge and release this!

[corydeppen]

@jbaxleyiii Including functions from the specific lodash-es modules increased the size of the bundle. I didn't want to tweak the bundlesize threshold until I knew you were okay with the approach.

[bjrnt]

Is there any way we could get this merged? Seems like this issue is holding up more than 20 teams from upgrading to v.2 based on the reactions to #1286.

[jbaxleyiii]

@corydeppen I'm really concerned about including all of lodash even with the es version for people who don't have bundlers that can remove it. 😢

I wonder if there is another way?

edit I don't know why the size is increasing since it is importing the file directly. I'll take a look and see how to get this merged today!

[KittyGiraudel]

I posted this comment on a commit but I cannot seem to find it anymore so allow me to submit it again here.

This change (apparently already published in 2.0.3, despite changelog mentioning vNext) seems to cause an error in our build:

SyntaxError: Unexpected token import
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:599:28)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Module.require (module.js:579:17)
    at require (internal/module.js:11:18)
    at /goldfish/node_modules/react-apollo/react-apollo.umd.js:2:123
/goldfish/node_modules/lodash-es/pick.js:1
(function (exports, require, module, __filename, __dirname) { import basePick from './_basePick.js';

Did we miss something maybe? Everything was (is) working fine in 2.0.1.

Thank you!

[doomsower]

I get same error as @hugogiraudel here after update, but only in jest tests. The app itself builds and runs fine
I'm using create-react-app-typescript

Here is my tsconfig.json:

{
  "compilerOptions": {
    "outDir": "build/dist",
    "module": "esnext",
    "target": "es5",
    "lib": ["es7", "dom", "esnext.asynciterable"],
    "sourceMap": true,
    "jsx": "react",
    "moduleResolution": "node",
    "rootDir": "src",
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "allowSyntheticDefaultImports": false,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  },
  "exclude": [
    "__mocks__",
    "node_modules",
    "build",
    "scripts",
    "acceptance-tests",
    "webpack",
    "jest",
    "src/setupTests.ts"
  ]
}

And for tests, tsconfig.test.json:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "module": "commonjs"
  }
}

[doomsower]

From this comment facebook/create-react-app#3001 (comment) I conclude that this problem should also affect regular create-react-app projects, not just typescript fork.

I see that in this PR @corydeppen works around this with transformIgnorePatterns, but this is impossible with create-react-app projects

[lednhatkhanh]

Since the fix has been rolled back, now I get the lodash error again...

[danrasmuson]

Any known workarounds while this issue gets resolved?

[kandros]

still looking for a workaroud, any idea?