Cannot resolve fibers in optimism
viztor opened this issue · comments
WARNING in ./node_modules/optimism/lib/local.js
Module not found: Error: Can't resolve 'fibers' in '/Users/***/node_modules/optimism/lib'
@ ./node_modules/optimism/lib/local.js
@ ./node_modules/optimism/lib/index.js
@ ./node_modules/apollo-cache-inmemory/lib/optimism.js
@ ./node_modules/apollo-cache-inmemory/lib/readFromStore.js
@ ./node_modules/apollo-cache-inmemory/lib/index.js
What version of optimism
are you using?
Got this also with optimism@0.6.5
What bundler are you using? Webpack? Rollup? Something else? The import of fibers
should fail and be caught, so any error reported by your bundler is a false positive:
Lines 11 to 18 in 84624ab
Please feel free to provide any more information that seems relevant.
I'm using Webpack. It is just a warning
I was just bit confused and concerned if there were something wrong on my end.
From your reply, It appears it's just a global-checking mechanism.
I guess this post can serve to that others won't be concerned about it when searched it online.
I'm not sure how other lib handle things like this, or maybe there's something wrong with my webpack config?
yarn said the following:
apollo-cache-inmemory@^1.3.0-beta.6:
version "1.3.0-beta.6"
resolved "***"
dependencies:
apollo-cache "^1.1.13"
apollo-utilities "^1.0.17"
optimism "^0.6.5"
optimism@^0.6.5:
version "0.6.5"
resolved "***"
dependencies:
immutable-tuple "^0.4.4"
Webpack also. Thanks.
Got the warning too, using apollo-cache-inmemory
which depends on optimism
I see the same warning - also using apollo inmemory cache. Looks like index.js
is importing local.js
which is importing fibers
, but fibers
is only declared as a devDepenency
.
This happens with webpack >= 4.16.2: https://github.com/webpack/webpack/releases/tag/v4.16.2
Related change: handle module.require like require
Here is an related issue: webpack/webpack#7777
Any plan on fixing it?
Does everyone understand the point of the code in question?
The goal is to import fibers
if and only if the package is installed in node_modules
, and otherwise silently swallow the exception. Webpack is attempting to be "helpful" with webpack/webpack#7750, but fails to accommodate this legitimate use case (which works fine in Node and other runtime module systems)—another noisy warning perched precariously atop a mountain of unspecified hacks. Just so everyone is on the same page.
We've already "fixed" this sort of problem once before, but I suppose we will have to keep working around Webpack's unsound and incomplete attempts to statically analyze this code.
This approach (just published in optimism@0.6.6
) ought to buy us some time:
Line 12 in 5cc2edd
Your move, Webpack. But also… could you just… not? 😂