This version is not covered by your current version range.
Without accepting this pull request your project will work just like it did before. There might be a bunch of new features, fixes and perf improvements that the maintainers worked on for you though.
I recommend you look into these changes and try to get onto the latest version of npm.
Given that you have a decent test suite, a passing build is a strong indicator that you can take advantage of these changes by merging the proposed change into your project. Otherwise this branch is a great starting point for you to work on the update.
Do you have any ideas how I could improve these pull requests? Did I report anything you think isn’t right?
Are you unsure about how things are supposed to work?
There is a collection of frequently asked questions and while I’m just a bot, there is a group of people who are happy to teach me new things. Let them know.
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.
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)
Hello lovely humans,
npm just published its new version 4.0.2.
This version is not covered by your current version range.
Without accepting this pull request your project will work just like it did before. There might be a bunch of new features, fixes and perf improvements that the maintainers worked on for you though.
I recommend you look into these changes and try to get onto the latest version of npm. Given that you have a decent test suite, a passing build is a strong indicator that you can take advantage of these changes by merging the proposed change into your project. Otherwise this branch is a great starting point for you to work on the update.
Do you have any ideas how I could improve these pull requests? Did I report anything you think isn’t right? Are you unsure about how things are supposed to work?
There is a collection of frequently asked questions and while I’m just a bot, there is a group of people who are happy to teach me new things. Let them know.
Good luck with your project :sparkles:
You rock!
:palm_tree:
GitHub Release
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@4as 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 outnpm@4so 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@4intonpm@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 beforenpm@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 newprepublishOnlyevent 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).8b32d67#14502 Simplify lifecycle invocation and fixprepublishOnly. (@othiym23)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:
What this doesn't mean:
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.
ab630c9#14503 Node 6 is LTS; 5.x, 0.10, and 0.12 are unsupported. (@othiym23)731ae52#14503 Update supported version expression. (@othiym23)DISENTANGLING SCOPE
The new
Npm-Scopeheader was previously reusing thescopeconfiguration 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 configuringscopein 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 ofnpm@4.0.1,npm shrinkwrapnow includesdevDependenciesunless instructed otherwise. (@iarna)bdc2f9e#14501 TheENOSELFerror 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
a52d0f0glob@7.1.1:absoluteoption. (@isaacs, @phated)afda66disaacs/node-graceful-fs#97graceful-fs@4.1.10: Better backoff for EPERM on Windows. (@sam-github)e0023c0npm/inflight#3inflight@1.0.6: Clean up even if / when a callback throws. (@phated)1d91594request@2.78.0(@othiym23)The new version differs by 401 commits .
6f34aa24.0.24639b0edoc: update changelog for 4.0.23e57950scripts: don't rely on latest being checked out1d91594code>request@2.78.0</codee0023c0code>inflight@1.0.6</codeafda66dcode>graceful-fs@4.1.10</codea52d0f0code>glob@7.1.1</code7f41295doc: Document new shrinkwrap dev dep behavior8b32d67publish: simplify lifecycle invocation731ae52unsupported: update supported version expressionab630c9ci: Node 6 is LTS, 0.10 & 0.12 are unsupported42b8be8doc: add a little note about ENOSELF in install.mdbdc2f9eerrors: clarifying the ENOSELF error message a bit39358f7config: differentiate scope from project scope in config1f22822test: failing test for aggressive scopingThere are 250 commits in total. See the full diff.
This pull request was created by greenkeeper.io.
Tired of seeing this sponsor message? :zap:
greenkeeper upgrade