|
| 1 | +### v3.3.12 (2015-11-02): |
| 2 | + |
| 3 | +Hi, a little hot-fix release for a bug introduced in 3.3.11. The ENOENT fix |
| 4 | +last week ([`f0e2088`](https://github.com/npm/npm/commit/f0e2088)) broke |
| 5 | +upgrades of modules that have bundled dependencies (like `npm`, augh!) |
| 6 | + |
| 7 | +* [`aedf7cf`](https://github.com/npm/npm/commit/aedf7cf) |
| 8 | + [#10192](//github.com/npm/npm/pull/10192) |
| 9 | + If a bundled module is going to be replacing a module that's currently on |
| 10 | + disk (for instance, when you upgrade a module that includes bundled |
| 11 | + dependencies) we want to select the version from the bundle in preference |
| 12 | + over the one that was there previously. |
| 13 | + ([@iarna](https://github.com/iarna)) |
| 14 | + |
| 15 | +### v3.3.11 (2015-10-29): |
| 16 | + |
| 17 | +This is a dependency update week, so that means no PRs from our lovely |
| 18 | +users. Look for those next week. As it happens, the dependencies updated |
| 19 | +were just devdeps, so nothing for you all to worry about. |
| 20 | + |
| 21 | +But the bug fixes, oh geez, I tracked down some really long standing stuff |
| 22 | +this week!! The headliner is those intermittent `ENOENT` errors that no one |
| 23 | +could reproduce consistently? I think they're nailed! But also pretty |
| 24 | +important, the bug where `hapi` would install w/ a dep missing? Squashed! |
| 25 | + |
| 26 | +#### EEEEEEENOENT |
| 27 | + |
| 28 | +* [`f0e2088`](https://github.com/npm/npm/commit/f0e2088) |
| 29 | + [#10026](https://github.com/npm/npm/issues/10026) |
| 30 | + Eliminate some, if not many, of the EONENT errors `npm@3` has seen over |
| 31 | + the past few months. This was happening when npm would, in its own mind, |
| 32 | + correct a bundled dependency, due to a `package.json` specifying an |
| 33 | + incompatible version. Then, when npm extracted the bundled version, what |
| 34 | + was on disk didn't match its mind and… well, when it tried to act on what |
| 35 | + was in its mind, we got an `ENOENT` because it didn't actually exist on |
| 36 | + disk. |
| 37 | + ([@iarna](https://github.com/iarna)) |
| 38 | + |
| 39 | +#### PARTIAL SHRINKWRAPS, NO LONGER A BAD DAY |
| 40 | + |
| 41 | +* [`712fd9c`](https://github.com/npm/npm/commit/712fd9c) |
| 42 | + [#10153](https://github.com/npm/npm/pull/10153) |
| 43 | + Imagine that you have a module, let's call it `fun-time`, and it depends |
| 44 | + on two dependencies, `need-fun@1` and `need-time`. Further, `need-time` |
| 45 | + requires `need-fun@2`. So after install the logical tree will look like |
| 46 | + this: |
| 47 | + |
| 48 | + ``` |
| 49 | + fun-time |
| 50 | + ├── need-fun@1 |
| 51 | + └── need-time |
| 52 | + └── need-fun@2 |
| 53 | + ``` |
| 54 | + |
| 55 | + Now, the `fun-time` author also distributes a shrinkwrap, but it only includes |
| 56 | + the `need-fun@1` in it. |
| 57 | + |
| 58 | + Resolving dependencies would look something like this: |
| 59 | + |
| 60 | + 1. Require `need-fun@1`: Use version from shrinkwrap (ignoring version) |
| 61 | + 2. Require `need-time`: User version in package.json |
| 62 | + 1. Require `need-fun@2`: Use version from shrinkwrap, which oh hey, is |
| 63 | + already installed at the top level, so no further action is needed. |
| 64 | + |
| 65 | + Which results in this tree: |
| 66 | + |
| 67 | + ``` |
| 68 | + fun-time |
| 69 | + ├── need-fun@1 |
| 70 | + └── need-time |
| 71 | + ``` |
| 72 | + |
| 73 | + We're ignoring the version check on things specified in the shrinkwrap |
| 74 | + so that you can override the version that will be installed. This is |
| 75 | + because you may want to use a different version than is specified |
| 76 | + by your dependencies' dependencies' `package.json` files. |
| 77 | + |
| 78 | + To fix this, we now only allow overrides of a dependency version when |
| 79 | + that dependency is a child (in the tree) of the thing that requires it. |
| 80 | + This means that when we're looking for `need-fun@2` we'll see `need-fun@1` |
| 81 | + and reject it because, although it's from a shrinkwrap, it's parent is |
| 82 | + `fun-time` and the package doing the requiring is `need-time`. |
| 83 | + |
| 84 | + ([@iarna](https://github.com/iarna)) |
| 85 | + |
| 86 | +#### STRING `package.bin` AND NON-NPMJS REGISTRIES |
| 87 | + |
| 88 | +* [`3de1463`](https://github.com/npm/npm/commit/3de1463) |
| 89 | + [#9187](https://github.com/npm/npm/issues/9187) |
| 90 | + If you were using a module with the `bin` field in your `package.json` set |
| 91 | + to a string on a non-npmjs registry then npm would crash, due to the our |
| 92 | + expectation that the `bin` field would be an object. We now pass all |
| 93 | + `package.json` data through a routine that normalizes the format, |
| 94 | + including the `bin` field. (This is the same routine that your |
| 95 | + `package.json` is passed through when read off of disk or sent to the |
| 96 | + registry for publication.) Doing this also ensures that older modules on |
| 97 | + npm's own registry will be treated exactly the same as new ones. (In the |
| 98 | + past we weren't always super careful about scrubbing `package.json` data |
| 99 | + on publish. And even when we were, those rules have subtly changed over |
| 100 | + time.) |
| 101 | + ([@iarna](https://github.com/iarna)) |
| 102 | + |
1 | 103 | ### v3.3.10 (2015-10-22): |
2 | 104 |
|
3 | 105 | Hey you all! Welcome to a busy bug fix and PR week. We've got changes |
|
0 commit comments