Fix#5658
Note that this doesn't actually *ignore* the files specified by the
.gitignore and/or .npmignore files. That would likely require removing
them after the fact, as well as all the same logic that exists in
fstream-npm, since tar does not give us a directory listing, and
tarballs may have their files in any random order.
The primary purpose is so that everything doing network requests
includes auth, if so required. Sends bearer token by default, will send
HTTP Basic auth with `always-auth` set in the config.
A previous fix for https://github.com/npm/npm/issues/3117
explicitly set the permissions for all files to a hard-coded
value, regardless of what the permissions were previously.
This changes that behavior to *add* the permissions that were
previously being *set* so that existing execute permissions are
maintained.
This is a redo of the much more blunt solution attempted in
https://github.com/npm/npm/pull/5728
thanks to some very helpful feedback from @othiym23
It's hard for me to construct a scenario where an optional dependency
with a plainly invalid name failing to install is actually useful to
anyone, so I nerfed the relevant line in the test.
Scope all cache files under the registry hostname, using the
npm-cache-filename module.
TODO: also store tarball files in the same spots, so that two
files from different registries don't clobber one another.
This probably undesirable behaviour stems from normalize-package-data:
> The values in optionalDependencies get added to dependencies. The
optionalDependencies array is left untouched.
Solution Caveat: regular dependencies that are also optional (does that
even make sense?) will not be updated with --save because there's no
way to detect which optional dependencies aren't also regular
dependencies – we just avoid updating anything optional during --save.
Some environments have a configured depth=x - if that depth is 0,
like on travis or any other possible machine, the test failed.
This passes Infinity, which is the current default in npmconf
The test in 8b5e7b6a fails as it depends on a unconfigured npm
which uses exact the same values as a vanilla npmconf instance.
This fix also does not depends on the external dependency npmconf.
