Apollo-client: [apollo-cache-inmemory] ESLint problems importing InMemoryCache

[nabiltntn]

Intended outcome:

After installing apollo-cache-inmemory, import and use InMemoryCache

Actual outcome:
Errors in ESlint and when starting application.

Line 2:  Unable to resolve path to module 'apollo-cache-inmemory'  import/no-unresolved
Line 2:  Missing file extension for "apollo-cache-inmemory"        import/extensions

How to reproduce the issue:

Install the package and import InMemoryCache using

import { InMemoryCache } from 'apollo-cache-inmemory';

Version

• "apollo-cache-inmemory": "^1.1.1"
• "apollo-client": "^2.0.3"
• "apollo-link": "^1.0.3"
• "apollo-link-context": "^1.0.1"
• "apollo-link-http": "^1.2.0"

[stefanmaric]

Experiencing the same.

[nabiltntn]

It works when adding /lib :

import { InMemoryCache } from 'apollo-cache-inmemory/lib';

Is it the intended way ?

[stefanmaric]

Is it the intended way ?

I don't think so. Probably has something to do with this PR: https://github.com/apollographql/apollo-client/pull/2466

[jbaxleyiii]

@kamilkisiela do you have any idea why this happened?

[kamilkisiela]

@jbaxleyiii I did some testing and it seems ESLint doesn't care about package.json's main field. If I set main: "./lib/index.js" ESLint warns that apollo-cache-inmemory/index.js is missing. Which is true but because there is no ./index.js this is why we have main in package.json to point to the entry file.
I could set there any path, it still won't work.

We could publish apollo-cache-inmemory the same way we do with apollo-client, meaning all the files would be in root directory of a package. I checked and it solves the issue.

[kamilkisiela]

@jbaxleyiii About the publishing process. Since all packages share exact same file structure and have the same values for package.json's main, jsnext:main, module we could do in apollo-client the same thing I did in apollo-angular.

Lerna mono repo. Every package has the npm script called deploy that is placed in scripts/deploy.sh.
This way I run npm run deploy in root to publish all or cd packages/<name> && npm run deploy to publish just one.

We could create a repository to keep those scripts so we can use them in many places (apollo-angular, apollo-client, apollo-link etc).

We could even automate it to run npm run deploy [email protected] --tag latest or use 3rd party package to handle this. I created something simple @kamilkisiela/scripts

[mechanical-turk]

For those who had this error start happening out of nowhere, it's probably because you're using ^ in your package json. Npm adds this by default when you install packages. It will make your package manager download the latest major version. For example, if your package version in your package.json is {"apollo-cache-inmemory": "^1.1.1"}, and the latest version is 1.9999.9999, your package manager will download 1.9999.9999. This won't happen in your local dev environment. You probably saw this error in a continuous integration environment while deploying. Its' because that environment will download the latest major version.

If you want a quick fix, just take out that nasty ol ^ out of the version string.

Steps:

1) "apollo-cache-inmemory": "^1.1.1" --> "apollo-cache-inmemory": "1.1.1"
2) delete node_modules
3) delete package-lock.json
4) run npm install

[jbaxleyiii]

@kamilkisiela thanks for the feedback! I'm working on making the repo easier to interact with so those are great things to know!

[niieani]

Actually, the reason for this issue is that path for jsnext:main is wrong in all the the packages, e.g.:

https://github.com/apollographql/apollo-client/blob/37e6f9b8adc1bf2fc12bb8c3cb5c2aa898702ce2/packages/apollo-cache-inmemory/package.json#L12-L15

You can see that it's missing a . in front. This causes the eslint rule to resolve it from the root instead of relative to the package.

The bugs were introduced in #2466. Another issue is that MapCache, which is not re-exported is now unusable from Node (only when building with Webpack) since it's not exposed in index (on purpose, I didn't want to add it to the bundle, since it would increase it's size).

To make #2466 even more solid, all the package.json's should also include sideEffects: false. Webpack 4 will use that information to truly tree-shake re-exported properties. Right now #2466 won't really have much of an effect, because re-exported properties are not properly tree-shaken in Webpack.

[jbaxleyiii]

@niieani this is great information! I'll work on fixing this for the next build and if you have any other ideas on how to improve our bundlesize / this?

[niieani]

@jbaxleyiii Nothing more comes to my mind at this time, just the sideEffects tip I mentioned above. As for the fix, we can actually do without ./ in the main/module/jsnext:main/typings fields, because they're implicitly relative: i.e. lib/index or lib/index.js should be enough.

[WaldoJeffers]

Any updates on this?

[glennreyes]

@niieani @jbaxleyiii IIRC I think we can open a PR fixing the path of jsnext:main?

[niieani]

@glennblock I'm only a contributor (not a maintainer), but I say go for it! :)

[glennblock]

Wrong Glenn :-)

[glennreyes]

👋 @glennblock nvm ... all good 👉 https://github.com/apollographql/apollo-client/pull/2648

[niieani]

Sorry about that @glennblock, I blame GitHub's autocomplete 😂

PR looks good enough to fix for now @glennreyes. 👏

[glennblock]

@niieani all good. I didn't think I had filed any issues against apollo, but still happy to here :-)