diff options
author | Rebecca Turner <me@re-becca.org> | 2015-10-30 02:28:37 +0300 |
---|---|---|
committer | Rebecca Turner <me@re-becca.org> | 2015-10-30 03:47:54 +0300 |
commit | 8a141adf3da0b0e0bb3feebe23c61be996d9bce3 (patch) | |
tree | 10c623bdf7464cdaaa781c9437887a0ca4a74626 | |
parent | f0e2088b3e7e084d67cada535a539d71885d32c9 (diff) |
doc: CHANGELOG for 3.3.11
-rw-r--r-- | CHANGELOG.md | 88 |
1 files changed, 88 insertions, 0 deletions
diff --git a/CHANGELOG.md b/CHANGELOG.md index a37a68bd7..250980902 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,91 @@ +### v3.3.11 (2015-10-29): + +This is a dependency update week, so that means no PRs from our lovely +users. Look for those next week. As it happens, the dependencies updated +were just devdeps, so nothing for you all to worry about. + +But the bug fixes, oh geez, I tracked down some really long standing stuff +this week!! The headliner is those intermittent `ENOENT` errors that no one +could reproduce consistently? I think they're nailed! But also pretty +important, the bug where `hapi` would install w/ a dep missing? Squashed! + +#### EEEEEEENOENT + +* [`f0e2088`](https://github.com/npm/npm/commit/f0e2088) + [#10026](https://github.com/npm/npm/issues/10026) + Eliminate some, if not many, of the EONENT errors `npm@3` has seen over + the past few months. This was happening when npm would, in its own mind, + correct a bundled dependency, due to a `package.json` specifying an + incompatible version. Then, when npm extracted the bundled version, what + was on disk didn't match its mind and… well, when it tried to act on what + was in its mind, we got an `ENOENT` because it didn't actually exist on + disk. + ([@iarna](https://github.com/iarna)) + +#### PARTIAL SHRINKWRAPS, NO LONGER A BAD DAY + +* [`712fd9c`](https://github.com/npm/npm/commit/712fd9c) + [#10153](https://github.com/npm/npm/pull/10153) + Imagine that you have a module, let's call it `fun-time`, and it depends + on two dependencies, `need-fun@1` and `need-time`. Further, `need-time` + requires `need-fun@2`. So after install the logical tree will look like + this: + + ``` + fun-time + ├── need-fun@1 + └── need-time + └── need-fun@2 + ``` + + Now, the `fun-time` author also distributes a shrinkwrap, but it only includes + the `need-fun@1` in it. + + Resolving dependencies would look something like this: + + 1. Require `need-fun@1`: Use version from shrinkwrap (ignoring version) + 2. Require `need-time`: User version in package.json + 1. Require `need-fun@2`: Use version from shrinkwrap, which oh hey, is + already installed at the top level, so no further action is needed. + + Which results in this tree: + + ``` + fun-time + ├── need-fun@1 + └── need-time + ``` + + We're ignoring the version check on things specified in the shrinkwrap + so that you can override the version that will be installed. This is + because you may want to use a different version than is specified + by your dependencies' dependencies' `package.json` files. + + To fix this, we now only allow overrides of a dependency version when + that dependency is a child (in the tree) of the thing that requires it. + This means that when we're looking for `need-fun@2` we'll see `need-fun@1` + and reject it because, although it's from a shrinkwrap, it's parent is + `fun-time` and the package doing the requiring is `need-time`. + + ([@iarna](https://github.com/iarna)) + +#### STRING `package.bin` AND NON-NPMJS REGISTRIES + +* [`3de1463`](https://github.com/npm/npm/commit/3de1463) + [#9187](https://github.com/npm/npm/issues/9187) + If you were using a module with the `bin` field in your `package.json` set + to a string on a non-npmjs registry then npm would crash, due to the our + expectation that the `bin` field would be an object. We now pass all + `package.json` data through a routine that normalizes the format, + including the `bin` field. (This is the same routine that your + `package.json` is passed through when read off of disk or sent to the + registry for publication.) Doing this also ensures that older modules on + npm's own registry will be treated exactly the same as new ones. (In the + past we weren't always super careful about scrubbing `package.json` data + on publish. And even when we were, those rules have subtly changed over + time.) + ([@iarna](https://github.com/iarna)) + ### v3.3.10 (2015-10-22): Hey you all! Welcome to a busy bug fix and PR week. We've got changes |