Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

2.1.0 breaks compose if you're using lodash-webpack-plugin #1831

Closed
nbudin opened this issue Mar 23, 2018 · 2 comments
Closed

2.1.0 breaks compose if you're using lodash-webpack-plugin #1831

nbudin opened this issue Mar 23, 2018 · 2 comments
Labels
docs Focuses on documentation changes has-reproduction ❤ Has a reproduction in a codesandbox or single minimal repository

Comments

@nbudin
Copy link

nbudin commented Mar 23, 2018

I should preface this by saying that I don't think this is exactly Apollo's fault, nor am I sure it's Apollo's problem - but I wanted to document this issue and the results of my investigation into it.

Intended outcome:

I've got an app that uses react-apollo in conjunction with babel-plugin-lodash and lodash-webpack-plugin. It uses the compose function as documented in Apollo's official docs, passing in several functions as separate arguments to be composed. I expect this to result in the functions being composed together.

Actual outcome:

react-apollo 2.1.0 uses lodash's flowRight function directly as its implementation of compose. flowRight has a behavior (implemented using lodash's private _flatRest function) that will cause it to treat multiple arguments as if you passed an array into it. However, lodash-webpack-plugin replaces _flatRest with identity.

The result is a rather cryptic error for components that use compose:

TypeError: funcs.reverse is not a function
(anonymous function)
src/react-apollo-error-template/node_modules/react-apollo/node_modules/lodash/_createFlow.js:31
./src/App.js
src/react-apollo-error-template/src/App.js:39
__webpack_require__
src/react-apollo-error-template/webpack/bootstrap 7b6a0c76843157e3146b:678
fn
src/react-apollo-error-template/webpack/bootstrap 7b6a0c76843157e3146b:88
./src/index.js
http://localhost:3001/static/js/bundle.js:58714:63
__webpack_require__
src/react-apollo-error-template/webpack/bootstrap 7b6a0c76843157e3146b:678
fn
src/react-apollo-error-template/webpack/bootstrap 7b6a0c76843157e3146b:88
0
http://localhost:3001/static/js/bundle.js:58761:18
__webpack_require__
src/react-apollo-error-template/webpack/bootstrap 7b6a0c76843157e3146b:678
(anonymous function)
src/react-apollo-error-template/webpack/bootstrap 7b6a0c76843157e3146b:724
(anonymous function)
http://localhost:3001/static/js/bundle.js:728:10

This happens because flowRight expects its funcs argument to be an array, but because lodash-webpack-plugin replaced _flatRest with identity, it's still being passed a bunch of functions as separate arguments.

Again, this is not really Apollo's fault. But it might be worth documenting somewhere that using lodash-webpack-plugin can break things in subtle ways, since it seems like Apollo is increasing its reliance on lodash.

How to reproduce the issue:

https://github.com/nbudin/react-apollo-error-template/tree/2.1.0-compose-lodash-webpack-plugin

Version

@ghost ghost added docs Focuses on documentation changes has-reproduction ❤ Has a reproduction in a codesandbox or single minimal repository labels Mar 23, 2018
@pleunv
Copy link

pleunv commented Mar 26, 2018

Running into the same issue here.

You can temporarily work around this by passing flattening: true to your lodash plugin:

new LodashModuleReplacementPlugin({
  // Necessary as a workaround for https://github.com/apollographql/react-apollo/issues/1831
  flattening: true
}),

@rosskevin
Copy link
Contributor

I'm not sure where we could document all permutations of build tool-chains etc, but I think your excellent description is documentation enough to be indexed and searchable from google given the specificity.

I mentioned to @benjamn we need to stop re-exporting it in #2661 (comment) this is another reason why we shouldn't be re-exporting a function from another library - it implicitly requires users with different build config/optimizations to dig and and discover lurking potential problems that would normally be obvious if you desire to use lodash.flowright and imported it directly in your own code.

Thanks for sharing your findings.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
docs Focuses on documentation changes has-reproduction ❤ Has a reproduction in a codesandbox or single minimal repository
Projects
None yet
Development

No branches or pull requests

3 participants