Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
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 internal
gunzip-maybeutility for optional gunzipping. (@zkat)
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
So now, any time a crash happens, we'll save your debug logs to your cache folder, under
~/.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)/_logsand store multiple log files. (@KenanY) (@othiym23) (@isaacs) (@iarna)
ae8e71c#15402 Add missing backtick in one of the
npm doctormessages. (@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 to
af06aa9#15520 Add section to
npm-scopedocs to explain that scope owners will own scoped packages with that scope. That is, user
@aliceis not allowed to publish to
@bob/my-packageunless explicitly made an owner by user (or org)
httpsand fix typos in some docs. (@watilde)
1dfe875#15545 Update Node.js download link to point to the right place. (@watilde)