npm / arborist / #93

push

Refactor shrinkwrap for correctness and elegance

Since the Shrinkwrap class was developed prior to figuring out exactly
how it would be used in the various Arborist methods, some things ended
up growing in a somewhat inelegant direction.

- Nodes were fetching their resolved and integrity values in multiple
  places.
- The Shrinkwrap internal data tried to keep up both the new and old
  data up to date as the tree changed, but this was not always possible.
- Dependencies of link targets were not properly reflected in the legacy
  shrinkwrap metadata.
- The Node class and buildIdealTree methods both had to dive deep into
  the internals of the YarnLock class, which should be an implementation
  detail of the Shrinkwrap class.

Now, the Shrinkwrap object keeps a reference to the root tree node found at
its own path.  Rather than try to keep the legacy metadata in sync at
all times, we _only_ build up the legacy shrinkwrap data when calling
`this.commit()`, by walking the `node.children` and
`node.target.children` maps appropriately.

Also, `this.yarnLock` is updated on commit(), and a `checkYarnLock()`
method is added to return the spec that should be fetched, and update
the provided options object with resolved and integrity metadata.

All of the logic for setting node metadata from the Shrinkwrap is now
done in `Shrinkwrap.add(node)`, making it much simpler and harder to get
wrong.

This means that:

- `yarn.lock` files are respected more fully (including their resolved
  and integrity expectations)
- We don't have cases where both `extraneous` and `dev`/`optional` are
  set in the lockfile (which is always an error -- extraneous nodes
  cannot be either dev or optional!)
- Link target dependencies are accurately reflected in the legacy
  shrinkwrap data, rather than creating invalid `../` entries.

1866 of 1866 branches covered (100.0%)

Branch coverage included in aggregate %.

2800 of 2800 relevant lines covered (100.0%)

314.42 hits per line