Releases: npm/npm
v4.3.0
Yay! Release time! It's a rainy day, and we have another smallish release for y'all. These things are not necessarily related. Or are they 🌧🤔
As far as news go, you may have noticed that the CLI team dropped support fornode@0.12
when that version went out of maintenance. Still, we've avoided explicitly breaking it and node@0.10
so far -- but not much longer.
Sometime soon, the CLI team plans on switching over to language features onlyavailable as of node@4 LTS
, and will likely start dropping old versions of node as they go out of maintenance. The new features are exciting! We're really looking forward to using them in the core CLI (and its dependencies) as we keep upwith our current feature work.
And speaking of features, this release is a minor bump due to a small change inhow npm login
works for the sake of supporting OAuth-based login for npmEnterprise users. But we won't leave the rest of y'all out -- we're working on a larger version of this feature. Soon enough, you'll be able to log in to npmwith, say, GitHub -- and use some shiny features that come from the integration. Or turn on 2FA and other such security features. Keep your eyes peeled for newon this in the next few releases and our weekly newsletter!
NEW AUTH TYPES
There's a new command line option: --auth-type
, which can be used to log in toa supporting registry with OAuth2 or SAML. The current implementation is mainly meant to support npmE customers, so if you're one of those: ask us about using it! If not, just hold off cause we'll have a much more complete version of this feature out soon.
ac8595e
bcf2dd8
9298d20
66b61bc
dc85de7
#13389 Implement single-sign-on support with--auth-type
option. (@zkat)
FASTER STARTUP. SOMETIMES!
request
is pretty heavy. And it loads a bunch of things. It's actually a pretty big chunk of npm's load time. This small patch by Rebecca will make it so npm only loads that module when we're actually intending to make network requests. Those of you who use npm commands that run offline might see a small speedup in startup time.
DOCUMENTATION
4ad9247
#15630 Fix formatting/rendering for root npm README. (@ungoldman)
DEPENDENCY UPDATES
v4.2.0
Hi all! I'm Kat, and I'm currently sitting in a train traveling at ~300km/h through Spain. So clearly, this release should have something to do with speed. And it does! Heck, with this release, you could say we're really blazing, even. 🌲🔥😏
IMPROVED CLI SEARCH~
You might recall if you've been keeping up that one of the reasons for a semver-major bump to npm@4
was an improved CLI search (read: no longer blowing up Node). The work done for that new search system, while still relying on a full metadata download and local search, was also meant to act as groundwork for then-ongoing work on a brand-new, smarter search system for npm. Shortly after npm@4
came out, the bulk of the server-side work was done, and with this release, the npm CLI has integrated use of the new endpoint for high-quality, fast-turnaround searches.
No, seriously, it's fast. And relevant:
Give it a shot! And remember to check out the new website version of the search, too, which uses the same backend as the CLI now. 🎉
Incidentally, the backend is a public service, so you can write your own search tools, be they web-based, CLI, or GUI-based. You can read up on the full documentation for the search endpoint, and let us know about the cool things you come up with!
ce3ca51
#15481 Add an internalgunzip-maybe
utility for optional gunzipping. (@zkat)e322932
a53055e
a1f4365
c56618c
#15481 Add support for using the new npm search endpoint for fast, quality search results. Includes a fallback to "classic" search. (@zkat)
WHERE DID THE DEBUG LOGS GO
This is another pretty significant change: Usually, when the npm process crashed, you would get an npm-debug.log
in your current working directory. This debug log would get cleared out as soon as you ran npm again. This was a bit annoying because 1) you would get a random file in your git status
that you might accidentally commit, and 2) if you hit a hard-to-reproduce bug and instinctually tried again, you would no longer have access to the repro npm-debug.log
.
So now, any time a crash happens, we'll save your debug logs to your cache folder, under _logs
(~/.npm
on *nix, by default -- use npm config get cache
to see what your current value is). The cache will now hold a (configurable) number of npm-debug.log
files, which you can access in the future. Hopefully this will help clean stuff up and reduce frustration from missed repros! In the future, this will also be used by npm report
to make it super easy to put up issues about crashes you run into with npm. 💃🕺🏿👯♂️
04fca22
#11439 Put debug logs in$(npm get cache)/_logs
and store multiple log files. (@KenanY) (@othiym23) (@isaacs) (@iarna)
DOCS
ae8e71c
#15402 Add missing backtick in one of thenpm doctor
messages. (@watilde, @charlotteis)821fee6
#15480 Clarify that unscoped packages can depend on scoped packages and vice-versa. (@chocolateboy)2ee45a8
#15515 Update minimum supported Node version number in the README tonode@>=4
. (@watilde)af06aa9
#15520 Add section tonpm-scope
docs to explain that scope owners will own scoped packages with that scope. That is, user@alice
is not allowed to publish to@bob/my-package
unless explicitly made an owner by user (or org)@bob
. (@hzoo)bc892e6
#15539 Replacehttp
withhttps
and fix typos in some docs. (@watilde)1dfe875
#15545 Update Node.js download link to point to the right place. (@watilde)
DEPENDENCIES
MISC
v4.1.2
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 #10223write-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 matchfs.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
521f230
node-gyp@3.5.0
: Improvements to how Python is located. New--devdir
flag. (@bnoordhuis) (@mhart)ccd83e8
JSONStream@1.3.0
: Add new emitPath option. (@nathanwills)
TEST IMPROVEMENTS
v4.1.1
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. Killing them was tricky because they constantly had new PIDs. There were a few tricks but the easiest was to just reboot.
Anyway, this is a quick release to fix that bug:
v4.1.0
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.
190a658
#15084 Add facility for recording and reporting success metrics. (@iarna)87afc8b
npm/npm-registry-client#147npm-registry-client@7.4.5
: Add support for sending anonymous CLI metrics.
(@iarna, @sisidovski)
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.
2359505
0209ee5
#14582 Add newnpm doctor
to give your project environment a health check. (@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#148npm-registry-client@7.4.5
: Fix a bug where anECONNRESET
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:
URL | Node.js <= 6 | npm's understanding | Node.js 7 | npm's understanding | |
---|---|---|---|---|---|
VALID | file:///abc/def | file:///abc/def | /abc/def | file:///abc/def | /abc/def |
invalid | file:/abc/def | file:/abc/def | /abc/def | file:///abc/def | /abc/def |
invalid | file:abc/def | file:abc/def | $CWD/abc/def | file://abc/def | /def on the abc host |
invalid | file:../abc/def | file:../abc/def | $CWD/../abc/def | file://../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
33ca4e6
#15157 Updatenpm cache
docs to use more consistent language (@JonahMoses)
DEPENDENCY UPDATES
c2d22fa
#15215nopt@4.0.1
: The breaking change is a small tweak to how empty string values are handled. See the brand-new CHANGELOG.md for nopt for further details about what's changed in this release! (@adius, @samjonester, @elidoran, @helio, @silkentrance, @othiym23)54d949b
npm/lockfile#24lockfile@1.0.3
: Handled case where callback was not passed in by the user. (@ORESoftware)54acc03
npmlog@4.0.2
: Documentation update. (@helio-frota)57f4bc1
osenv@0.1.4
: Test changes. (@isaacs)bea1a2d
retry@0.10.1
: No changes. (@tim-kos)6749e39
kapouer/marked-man#9marked-man@0.2.0
: Add table support. (@gholk)
v4.0.5
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
#15081bundledDependencies
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 ConsiderdevDependencies
when deciding whether to hoist a package. This should resolve a variety of missing dependency issues some folks were seeing whendevDependencies
happened to also be dependencies of yourdependencies
. This often manifested as modules going missing, or only being installed, afternpm 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. (@isaacs)85b0174
request@2.79.0
(@simov)9664d36
tap@8.0.1
(@isaacs)
MISCELLANEOUS
v4.0.3
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#46npmlog@4.0.1
: Fix a bug where the progress bar would still display even if you passed in--no-progress
. (@iarna)
DOCUMENTATION UPDATES
c3ac177
#14406 Sync up the dispute policy included with the CLI with the current official text. (@mike-engel)9c663b2
#14627 Update build status branch in README. (@cameronroe)8a8a0a3
#14609 Update examples URLs of GitHub repos where those repos have moved to new URLs. (@dougwilson)7a6425b
#14472 Documentsign-git-tag
in npm-version(1)'s configuration section. (@strugee)f3087cc
#14546 Add a note about the dangers of configuring npm via uppercase env vars. (@tuhoojabotti)50e51b0
#14559 Remove documentation that incorrectly stated that we check.npmrc
permissions. (@iarna)
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
aa73d1c
c914e80
58fe064
#14602 When running tests with coverage, use nyc's cache. This provides an 8x speedup! (@bcoe)ba091ce
#14435 Remove an unused zero bytepackage.json
found in the test fixtures. (@baderbuddy)
DEPENDENCY UPDATES
442e01e
readable-stream@2.2.2
: Bring in latest changes from Node.js 7.x. (@calvinmetcalf)bfc4a1c
which@1.2.12
: Remove unused require. (@isaacs)
DEV DEPENDENCY UPDATES
v3.10.10
v3.10.10 (2016-11-04)
See the discussion on #14042 for more context on this release, which is intended to address a serious regression in shrinkwrap behavior in the version of the CLI currently bundled with Node.js 6 LTS "Boron". You should never install this version directly; instead update to npm@4
, which has everything in this release and more.
REGRESSION FIX
9aebe98
#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)
UPDATE SUPPORT MATRIX
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.
v4.0.2
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.
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-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.
SMALLER CHANGES
7f41295
#14519 Document that as ofnpm@4.0.1
,npm shrinkwrap
now includesdevDependencies
unless instructed otherwise. (@iarna)bdc2f9e
#14501 TheENOSELF
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
a52d0f0
glob@7.1.1
:afda66d
isaacs/node-graceful-fs#97graceful-fs@4.1.10
: Better backoff for EPERM on Windows. (@sam-github)e0023c0
npm/inflight#3inflight@1.0.6
: Clean up even if / when a callback throws. (@phated)1d91594
request@2.78.0
(@othiym23)
v4.0.1
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 fornode
executables in both$PATH
andprocess.execPath
to avoid issues with symlinkednode
. (@addaleax)964f2d3
#14375 Make includingdevDependencies
innpm-shrinkwrap.json
the default. This should help make the transition tonpm@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)