npm / arborist / #74 / 1

push

fix: Handle tarball dependencies properly

For 'file:' deps (whether directory or tarball type), Node.resolved is
always absolute.  It was initially set up to be relative to the node
path, because it had to be stashed back to package.json.  But, then we
got rid of that approach in favor of a more comprehensive lockfile, and
so the added complexity of constantly re-evaluating the resolved value
as the node moves around serves no purpose.

This relative linking also _wasn't_ being handled properly in tarball
dependencies, resulting in attempting to fetch a tarball from the wrong
location, relative to the dependent's directory in node_modules, rather
than where it should be found.  Since we never store Node.resolved
anywhere, there's no need for it to be portable, and the portability had
a bug anyway.

*Shrinkwrap* files *do* have to be portable, so the paths get
relativized (and resolved) going into and out of lockfiles.  But that's
much simpler.

Tarball dependencies are more consistently handled, and now that the
Node.resolved value is absolute and predictable, it's easier to get that
right.

Tarball dependencies are properly regarded as a valid dependency
resolution, provided that they come from the same target file.  It's
still a bit of a crapshoot when we get legacy install trees, but at
least now we're not throwing out package._resolved when we load the
manifest from pacote directly.

The added test case installs a tarball dependency which depends on two
other tarballs: 1 in its own containing folder, and another outside of
its folder.  (This exact situation was a thorn in npm's side for most of
6.x, and might still be in some cases.)

1793 of 1793 branches covered (100.0%)

Branch coverage included in aggregate %.

2685 of 2685 relevant lines covered (100.0%)

233.22 hits per line