lukechilds
/
node
mirror of https://github.com/lukechilds/node.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
16585 Commits
131 Branches
446 Tags
325 MiB
 
 
 
 
 
 
Tree: 6123ed5b25
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '6123ed5b25'
${ noResults }
node/deps/npm/CHANGELOG.md

48 KiB
Raw Blame History

v4.1.2 (2017-01-12)

We have a twee little release this week as we come back from the holidays.

0.12 IS UNSUPPORTED NOW (really)

After jumping the gun a little, we can now officially remove 0.12 from our supported versions list. The Node.js project has now officially ended even maintenance support for 0.12 and thus, so will we. To reiterate from the last time we did this:

What this means:

  • Your contributions will no longer block on the tests passing on 0.12.
  • We will no longer block dependency upgrades on working with 0.12.
  • Bugs filed on the npm CLI that are due to incompatibilities with 0.12 (and older versions) will be closed with a strong urging to upgrade to a supported version of Node.
  • On the flip side, we'll continue to (happily!) accept patches that address regressions seen when running the CLI with Node.js 0.12.

What this doesn't mean:

  • The CLI is going to start depending on ES2015+ features. npm continues to work, in almost all cases, all the way back to Node.js 0.8, and our long history of backwards compatibility is a source of pride for the team.
  • We aren't concerned about the problems of users who, for whatever reason, can't update to newer versions of npm. As mentioned above, we're happy to take community patches intended to address regressions.

We're not super interested in taking sides on what version of Node.js you "should" be running. We're a workflow tool, and we understand that you all have a diverse set of operational environments you need to be able to support. At the same time, we are a small team, and we need to put some limits on what we support. Tracking what's supported by our runtime's own team seems most practical, so that's what we're doing.

WRITING TO SYMLINKED package.json (AND OTHER FILES)

If your package.json, npm-shrinkwrap.json or .npmrc were a symlink and you used an npm command that modified one of these (eg npm config set or npm install --save) then previously we would have removed your symlink and replaced it with an ordinary file. While making these files symlinks is pretty uncommon, this was still surprising behavior. With this fix we now overwrite the destination of the symlink and preserve the symlink itself.

  • a583983 write-file-atomic/#5 #10223 write-file-atomic@1.3.1: When the target is a symlink, write-file-atomic now overwrites the destination of the symlink, instead of replacing the symlink itself. This makes it's behavior match fs.writeFile.

    Fixed a bug where it would ALWAYS fs.stat to look up default mode and chown values even if you'd passed them in. (It still used the values you passed in, but did a needless stat.) (@iarna)

DEPENDENCY UPDATES

TEST IMPROVEMENTS

  • d76e084 Disable metric reporting for test suite even if the user has it enabled. (@iarna)

v4.1.1 (2016-12-16)

This fixes a bug in the metrics reporting where, if you had enabled it then installs would create a metrics reporting process, that would create a metrics reporting process, that would… well, you get the idea. The only way to actually kill these processes is to turn off your networking, then on MacOS/Linux kill them with kill -9. Alternatively you can just reboot.

Anyway, this is a quick release to fix that bug:

  • 51c393f #15237 Don't launch a metrics sender process if we're running from a metrics sender process. (@iarna)

v4.1.0 (2016-12-15)

I'm really excited about npm@4.1.0. I know, I know, I'm kinda overexcited in my changelogs, but this one is GREAT. We've got a WHOLE NEW subcommand, I mean, when was the last time you saw that? YEARS! And we have the beginnings of usage metrics reporting. Then there's a fix for a really subtle bug that resulted in shasum errors. And then we also have a few more bug fixes and other improvements.

ANONYMOUS METRIC REPORTING

We're adding the ability for you all to help us track the quality of your experiences using npm. Metrics will be sent if you run:

npm config set send-metrics true

Then npm will report to registry.npmjs.org the number of successful and failed installations you've had. The data contains no identifying information and npm will not attempt to correlate things like IP address with the metrics being submitted.

Currently we only track number of successful and failed installations. In the future we would like to find additional metrics to help us better quantify the quality of the npm experience.

NPM DOCTOR

Check                               Value                        Recommendation
npm ping                            ok
npm -v                              v4.0.5
node -v                             v4.6.1                       Use node v6.9.2
npm config get registry             https://registry.npmjs.org/
which git                           /Users/rebecca/bin/git
Perms check on cached files         ok
Perms check on global node_modules  ok
Perms check on local node_modules   ok
Checksum cached files               ok

It's a rare day that we add a new command to npm, so I'm excited to present to you npm doctor. It checks for a number of common problems and provides some recommended solutions. It was put together through the hard work of @watilde.

FIX MAJOR SOURCE OF SHASUM ERRORS

If you've been getting intermittent shasum errors then you'll be pleased to know that we've tracked down at least one source of them, if not THE source of them.

  • 87afc8b #14626 npm/npm-registry-client#148 npm-registry-client@7.4.5: Fix a bug where an ECONNRESET while fetching a package file would result in a partial download that would be reported as a "shasum mismatch". It now throws away the partial download and retries it. (@iarna)

FILE URLS AND NODE.JS 7

When npm was formatting file URLs we took advantage of url.format to construct them. Node.js 7 changed the behavior in such a way that our use of url.format stopped producing URLs that we could make use of.

The reasons for this have to do with the file URL specification and how invalid (according to the specification) URLs are handled. How this changed is most easily explained with a table:

URLNode.js <= 6npm's understandingNode.js 7npm's understanding
VALIDfile:///abc/deffile:///abc/def/abc/deffile:///abc/def/abc/def
invalidfile:/abc/deffile:/abc/def/abc/deffile:///abc/def/abc/def
invalidfile:abc/deffile:abc/def$CWD/abc/deffile://abc/def/def on the abc host
invalidfile:../abc/deffile:../abc/def$CWD/../abc/deffile://../abc/def/abc/def on the .. host

So the result was that passing a file URL that npm had received that used through Node.js 7's url.format changed its meaning as far as npm was concerned. As those kinds of URLs are, per the specification, invalid, how they should be handled is undefined and so the change in Node.js wasn't a bug per se.

Our solution is to stop using url.format when constructing this kind of URL.

EXTRANEOUS LIFECYCLE SCRIPT EXECUTION WHEN REMOVING

REFACTORING AND INTERNALS

  • c9b279a #15205 #15196 Only have one function that determines which version of a package to use given a specifier and a list of versions. (@iarna, @zkat)

  • 981ce63 #15090 Rewrite prune to use modern npm plumbing. (@iarna)

  • bc4b739 #15089 Rename functions and variables in the module that computes what changes to make to your installation. (@iarna)

  • 2449f74 #15089 When computing changes to make to your installation, use a function to add new actions to take instead of just pushing on a list. (@iarna)

IMPROVED LOGGING

DOCUMENTATION

DEPENDENCY UPDATES

v4.0.5 (2016-12-01)

It's that time of year! December is upon us, which means y'all are just going to be doing a lot less, in general, for the next month or so. The "Xmas Chasm", as we like to call it, has already begun. So for those of you reading it from the other side: Hi! Welcome back!

This week's release is a relatively small one, involving just a few bugfixes and dependency upgrades. The CLI team has been busy recently with scoping out npm@5, and starting to do initial spec work for in-scope stuff.

BUGFIXES

On to the actual changes!

  • 9776d8f #15081 bundledDependencies are intended to be left untouched by the installer, as much as possible -- if they're bundled, we assume that you want to be particular about the contents of your bundle.

    The installer used to have a corner case where existing dependencies that had bundledDependencies would get clobbered by as the installer moved stuff around, even though the installer already avoided moving deps that were themselves bundled. This is now fixed, along with the connected crasher, and your bundledDeps should be left even more intact than before! (@iarna)

  • fc61c08 #15082 Initialize nodes from bundled dependencies. This should address #14427 and related issues, but it's turned out to be a tremendously difficult issue to reproduce in a test. We decided to include it even pending tests, because we found the root cause of the errors. (@iarna)

  • d8471a2 #12811 Consider devDependencies when deciding whether to hoist a package. This should resolve a variety of missing dependency issues some folks were seeing when devDependencies happened to also be dependencies of your dependencies. This often manifested as modules going missing, or only being installed, after npm install was called twice. (@schmod)

DEPENDENCY UPDATES

  • 5978703 graceful-fs@4.1.11: EPERM errors are Windows are now handled more gracefully. Windows users that tended to see these errors due to, say, an antivirus-induced race condition, should see them much more rarely, if at all. (@zkatr)
  • 85b0174 request@2.79.0 (@zkat)
  • 9664d36 tap@8.0.1 (@zkat)

MISCELLANEOUS

v4.0.3 (2016-11-17)

Hey you all, we've got a couple of bug fixes for you, a slew of documentation improvements and some improvements to our CI environment. I know we just got v4 out the door, but the CLI team is already busy planning v5. We'll have more for you in early December.

BUG FIXES

  • 45d40d9 ba2adc2 1dc8908 2ba19ee #14403 Fix a bug where a scoped module could produce crashes when incorrectly computing the paths related to their location. This patch reorganizes how path information is passed in to eliminate the possibility of this sort of bug. (@iarna) (@NatalieWolfe)
  • 1011ec6 npm/npmlog#46 npmlog@4.0.1: Fix a bug where the progress bar would still display even if you passed in --no-progress. (@iarna)

DOCUMENTATION UPDATES

OH UH, HELLO AGAIN NODE.JS 0.12
  • 6f0c353 f78bde6 #14591 Reintroduce Node.js 0.12 to our support matrix. We jumped the gun when removing it. We won't drop support for it till the Node.js project does so at the end of December 2016. (@othiym23)

TEST/CI UPDATES

DEPENDENCY UPDATES

DEV DEPENDENCY UPDATES

v4.0.2 (2016-11-03)

Hola, amigxs. I know it's been a long time since I rapped at ya, but I been spending a lotta time quietly reflecting on all the things going on in my life. I was, like, in Japan for a while, and before that my swell colleagues @zkat and @iarna have been very capably managing the release process for quite a while. But I returned from Japan somewhat refreshed, very jetlagged, and filled with a burning urge to get npm@4 as stable as possible before we push it out to the user community at large, so I decided to do this release myself. (Also, huge thanks to Kat and Rebecca for putting out npm@4 so capably while I was on vacation! So cool to return to a major release having gone so well without my involvement!)

That said...

NEVER TRUST AN X.0.0 RELEASE

Even though 4.0.1 came out hard on the heels of 4.0.0 with a couple critical fixes, we've found a couple other major issues that we want to see fixed before making npm@4 into npm@latest. Some of these are arguably breaking changes on their own, so now is the time to get them out if we're going to do so before npm@5, and all of them are pretty significant blockers for a substantial number of users, so now is the best time to fix them.

PREPUBLISHONLY WHOOPS

The code running the publish* lifecycle events was very confusingly written. In fact, we didn't really figure out what it was doing until we added the new prepublishOnly event and it was running people's scripts from the wrong directory. We made it simpler. See the commit message for details.

Because the change is no longer running publish events when publishing prebuilt artifacts, it's technically a breaking / semver-major change. In the off chance that the new behavior breaks any of y'all's workflows, let us know, and we can roll some or all of this change back until npm@5 (or forever, if that works better for you).

G'BYE NODE.JS 0.10, 0.12, and 5.X; HI THERE, NODE 7

With the advent of the second official Node.js LTS release, Node 6.x 'Boron', the Node.js project has now officially dropped versions 0.10 and 0.12 out of the maintenance phase of LTS. (Also, Node 5 was never part of LTS, and will see no further support now that Node 7 has been released.) As a small team with limited resources, the npm CLI team is following suit and dropping those versions of Node from its CI test matrix.

What this means:

  • Your contributions will no longer block on the tests passing on 0.10 and 0.12.
  • We will no longer block dependency upgrades on working with 0.10 and 0.12.
  • Bugs filed on the npm CLI that are due to incompatibilities with 0.10 or 0.12 (and older versions) will be closed with a strong urging to upgrade to a supported version of Node.
  • On the flip side, we'll continue to (happily!) accept patches that address regressions seen when running the CLI with Node.js 0.10 and 0.12.

What this doesn't mean:

  • The CLI is going to start depending on ES2015+ features. npm continues to work, in almost all cases, all the way back to Node.js 0.8, and our long history of backwards compatibility is a source of pride for the team.
  • We aren't concerned about the problems of users who, for whatever reason, can't update to newer versions of npm. As mentioned above, we're happy to take community patches intended to address regressions.

We're not super interested in taking sides on what version of Node.js you "should" be running. We're a workflow tool, and we understand that you all have a diverse set of operational environments you need to be able to support. At the same time, we are a small team, and we need to put some limits on what we support. Tracking what's supported by our runtime's own team seems most practical, so that's what we're doing.

DISENTANGLING SCOPE

The new Npm-Scope header was previously reusing the scope configuration option to pass the current scope back to your current registry (which, as described previously, is meant to set up some upcoming registry features). It turns out that had some seriously weird consequences in the case where you were already configuring scope in your own environment. The CLI now uses separate configuration for this.

  • 39358f7 #14477 Differentiate registry scope from project scope in configuration. (@zkat)

SMALLER CHANGES

  • 7f41295 #14519 Document that as of npm@4.0.1, npm shrinkwrap now includes devDependencies unless instructed otherwise. (@iarna)
  • bdc2f9e #14501 The ENOSELF error message is tricky to word. It's also an error that normally bites new users. Clean it up in an effort to make it easier to understand what's going on. (@snopeks, @zkat)

DEPENDENCY UPGRADES

v4.0.1 (2016-10-24)

Ayyyy~ 🌊

So thanks to folks who were running on npm@next, we managed to find a few issues of notes in that preview version, and we're rolling out a small patch change to fix them. Most notably, anyone who was using a symlinked node binary (for example, if they installed Node.js through homebrew), was getting a very loud warning every time they ran scripts. Y'all should get warnings in a more useful way, now that we're resolving those path symlinks.

Another fairly big change that we decided to slap into this version, since npm@4.0.0 is never going to be latest, is to make it so devDependencies are included in npm-shrinkwrap.json by default -- if you do not want this, use --production with npm shrinkwrap.

BIG FIXES/CHANGES

  • eff46dd #14374 Fully resolve the path for node executables in both $PATH and process.execPath to avoid issues with symlinked node. (@addaleax)
  • 964f2d3 #14375 Make including devDependencies in npm-shrinkwrap.json the default. This should help make the transition to npm@5 smoother in the future. (@iarna)

BUGFIXES

  • a5b0a8d #14400 Recently, we've had some consistent timeout failures while running the test suite under Travis. This tweak to tests should take care of those issues and Travis should go back to being reliably green. (@iarna)

DOC PATCHES

v4.0.0 (2016-10-20)

Welcome to npm@4, friends!

This is our first semver major release since the release of npm@3 just over a year ago. Back then, @3 turned out to be a bit of a ground-shaking release, with a brand-new installer with significant structural changes to how npm set up your tree. This is the end of an era, in a way. npm@4 also marks the release when we move both npm@2 and npm@3 into maintenance: We will no longer be updating those release branches with anything except critical bugfixes and security patches.

While its predecessor had some pretty serious impaact, npm@4 is expected to have a much smaller effect on your day-to-day use of npm. Over the past year, we've collected a handful of breaking changes that we wanted to get in which are only breaking under a strict semver interpretation (which we follow). Some of these are simple usability improvements, while others fix crashes and serious issues that required a major release to include.

We hope this release sees you well, and you can look forward to an accelerated release pace now that the CLI team is done focusing on sustaining work -- our Windows fixing and big bugs pushes -- and we can start focusing again on usability, features, and performance. Keep an eye out for npm@5 in Q1 2017, too: We're planning a major overhaul of shrinkwrap as well as various speed and usability fixes for that release. It's gonna be a fun ride. I promise. 😘

BRIEF OVERVIEW OF BREAKING CHANGES

The following breaking changes are included in this release:

  • npm search rewritten to stream results, and no longer supports sorting.
  • npm scripts no longer prepend the path of the node executable used to run npm before running scripts. A --scripts-prepend-node-path option has been added to configure this behavior.
  • npat has been removed.
  • prepublish has been deprecated, replaced by prepare. A prepublishOnly script has been temporarily added, which will only run on npm publish.
  • npm outdated exits with exit code 1 if it finds any outdated packages.
  • npm tag has been removed after a deprecation cycle. Use npm dist-tag.
  • Partial shrinkwraps are no longer supported. npm-shrinkwrap.json is considered a complete installation manifest except for devDependencies.
  • npm's default git branch is no longer master. We'll be using latest from now on.

SEARCH REWRITE (BREAKING)

Let's face it -- npm search simply doesn't work anymore. Apart from the fact that it grew slower over the years, it's reached a point where we can no longer fit the entire registry metadata in memory, and anyone who tries to use the command now sees a really awful memory overflow crash from node.

It's still going to be some time before the CLI, registry, and web team are able to overhaul npm search altogether, but until then, we've rewritten the previous npm search implementation to stream results on the fly, from both the search endpoint and a local cache. In absolute terms, you won't see a performance increase and this patch does come at the cost of sorting capabilities, but what it does do is start outputting results as it finds them. This should make the experience much better, overall, and we believe this is an acceptable band-aid until we have that search endpoint in place.

Incidentally, if you want a really nice search experience, we recommend checking out npms.io, which includes a handy-dandy npms-cli for command-line usage -- it's an npm search site that returns high-quality results quickly and is operated by members of the npm community.

SCRIPT NODE PATH (BREAKING)

Thanks to some great work by @addaleax, we've addressed a fairly tricky issue involving the node process used by npm scripts.

Previously, npm would prefix the path of the node executable to the script's PATH. This had the benefit of making sure that the node process would be the same for both npm and scripts unless you had something like node-bin in your node_modules. And it turns out lots of people relied on this behavior being this way!

It turns out that this had some unintended consequences: it broke systems like nyc, but also completely broke/defeated things like rvm and virtualenv by often causing things that relied on them to fall back to the global system versions of ruby and python.

In the face of two perfectly valid, and used alternatives, we decided that the second case was much more surprising for users, and that we should err on the side of doing what those users expect. Anna put some hard work in and managed to put together a patch that changes npm's behavior such that we no longer prepend the node executable's path by default, and adds a new option, --scripts-prepend-node-path, to allow users who rely on this behavior to have it add the node path for them.

This patch also makes it so this feature is discoverable by people who might run into the first case above, by warning if the node executable is either missing or shadowed by another one in PATH. This warning can also be disabled with the --scripts-prepend-node-path option as needed.

  • 3fb1eb3 6a7d375 378ae08 #13409 Add a --scripts-prepend-node-path option to configure whether npm prepends the current node executable's path to PATH. (@addaleax)
  • 70b352c #13409 Change the default behaviour of npm to never prepending the current node executable’s directory to PATH but printing a warning in the cases in which it previously did. (@addaleax)

REMOVE npat (BREAKING)

Let's be real here -- almost no one knows this feature ever existed, and it's a vestigial feature of the days when the ideal for npm was to distribute full packages that could be directly developed on, even from the registry.

It turns out the npm community decided to go a different way: primarily publishing packages in a production-ready format, with no tests, build tools, etc. And so, we say goodbye to npat.

NEW prepare SCRIPT. prepublish DEPRECATED (BREAKING)

If there's anything that really seemed to confuse users, it's that the prepublish script ran when invoking npm install without any arguments.

Turns out many, many people really expected that it would only run on npm publish, even if it actually did what most people expected: prepare the package for publishing on the registry.

And so, we've added a prepare command that runs in the exact same cases where prepublish ran, and we've begun a deprecation cycle for prepublish itself only when run by npm install, which will now include a warning any time you use it that way.

We've also added a prepublishOnly script which will execute only when npm publish is invoked. Eventually, prepublish will stop executing on npm install, and prepublishOnly will be removed, leaving prepare and prepublish as two distinct lifecycles.

NO MORE PARTIAL SHRINKWRAPS (BREAKING)

That's right. No more partial shrinkwraps. That means that if you have an npm-shrinkwrap.json in your project, npm will no longer install anything that isn't explicitly listed there, unless it's a devDependency. This will open doors to some nice optimizations and make use of npm shrinkwrap just generally smoother by removing some awful corner cases. We will also skip devDependency installation from package.json if you added devDependencies to your shrinkwrap by using npm shrinkwrap --dev.

  • b7dfae8 #14327 Use readShrinkwrap to read top level shrinkwrap. There's no reason for npm to be doing its own bespoke heirloom-grade artisanal thing here. (@iarna)
  • 0ae1f4b 4a54997 f22a1ae 3f61189 #14327 Treat shrinkwrap as canonical. That is, don't try to fill in for partial shrinkwraps. Partial shrinkwraps should produce partial installs. If your shrinkwrap contains NO devDependencies then we'll still try to install them from your package.json instead of assuming you NEVER want devDependencies. (@iarna)

npm tag REMOVED (BREAKING)

  • 94255da #14328 Remove deprecated tag command. Folks must use the dist-tag command from now on. (@iarna)

NON-ZERO EXIT CODE ON OUTDATED DEPENDENCIES (BREAKING)

SEND EXTRA HEADERS TO REGISTRY

For the purposes of supporting shiny new registry features, we've started sending Npm-Scope and Npm-In-CI headers in outgoing requests.

  • 846f61c npm/npm-registry-client#145 npm/npm-registry-client#147 npm-registry-client@7.3.0:
    • Allow npm to add headers to outgoing requests.
    • Add Npm-In-CI header that reports whether we're running in CI. (@iarna)
  • 6b6bb08 #14129 Send Npm-Scope header along with requests to registry. Npm-Scope is set to the @scope of the current top level project. This will allow registries to implement user/scope-aware features and services. (@iarna)
  • 506de80 #14129 Add test to ensure Npm-In-CI header is being sent when CI is set in env. (@iarna)

BUGFIXES

  • bc84012 #14117 Fixes a bug where installing a shrinkwrapped package would fail if the platform failed to install an optional dependency included in the shrinkwrap. (@watilde)
  • a40b32d #13519 If a package has malformed metadata, node.requiredBy is sometimes missing. Stop crashing when that happens. (@creationix)

OTHER PATCHES

  • 643dae2 #14244 Remove some ancient aliases that we'd rather not have around. (@zkat)
  • bdeac3e #14230 Detect unsupported Node.js versions and warn about it. Also error on really old versions where we know we can't work. (@iarna)

DOC UPDATES

DEPENDENCIES