Output of npm config get cache changes based on working directory - is that intentional?

[rmacklin]

I'm opening this issue because:

• npm is crashing.
• npm is producing an incorrect install.
• npm is doing something I don't understand.
• Other (see below for feature requests): npm is doing something that I didn't expect, and I'd like to know if this behavior is intentional.

What's going wrong?

If I have an .npmrc in the project root with:

cache=tmp/node_cache

and I run npm config get cache from the root, it'll output:

<root>/tmp/node_cache

but if I run npm config get cache from <root>/subdir, it'll output:

<root>/subdir/tmp/node_cache

I was a bit surprised to see that the cache path is relative to the current working directory rather than the project root. I would like to know if this behavior is intentional or undesired.

How can the CLI team reproduce the problem?

git clone git@github.com:rmacklin/npmrc_cache_config_example.git
cd npmrc_cache_config_example
npm config get cache
cd subdir
npm config get cache

Observe the difference in the output:

npmrc_cache_config_example/tmp/node_cache

vs

npmrc_cache_config_example/subdir/tmp/node_cache

supporting information:

• npm -v prints: 3.10.4
• node -v prints: v6.2.0
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X, or Linux?: OS X
• Network issues:
  • Geographic location where npm was run: CA, USA
  • I use a proxy to connect to the npm registry.
  • I use a proxy to connect to the web.
  • I use a proxy when downloading Git repos.
  • I access the npm registry via a VPN
  • I don't use a proxy, but have limited or unreliable internet access.
• Container:
  • I develop using Vagrant on Windows.
  • I develop using Vagrant on OS X or Linux.
  • I develop / deploy using Docker.
  • I deploy to a PaaS (Triton, Heroku).

[npm-robot]

We're closing this issue as it has gone seven days without activity and without being labeled. If we haven't even labeled in issue in seven days then we're unlikely to ever read it.

If you are still experiencing the issue that led to you opening this or this is a feature request you're still interested in then we encourage you to open a new issue. If this was a support issue, you may be better served by joining package.communty and asking your question there.

For more information about our new issue aging policies and why we've instituted them please see our blog post.