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)