v2.10.0

THE IMPLICATIONS ARE MORE PROFOUND THAN THEY APPEAR

If you've done much development in The Enterprise®™, you know that keeping track of software licenses is far more important than one might expect / hope / fear. Tracking licenses is a hassle, and while many (if not most) of us have (reluctantly) gotten around to setting a license to use by default with all our new projects (even if it's just WTFPL), that's about as far as most of us think about it. In big enterprise shops, ensuring that projects don't inadvertently use software with unacceptably encumbered licenses is serious business, and developers spend a surprising (and appalling) amount of time ensuring that licensing is covered by writing automated checkers and other license auditing tools.

The Linux Foundation has been working on a machine-parseable syntax for license expressions in the form of SPDX, an appropriately enterprisey acronym. IP attorney and JavaScript culture hero Kyle Mitchell has put a considerable amount of effort into bringing SPDX to JavaScript and Node. He's written spdx.js, a JavaScript SPDX expression parser, and has integrated it into npm in a few different ways.

For you as a user of npm, this means:

• npm now has proper support for dual licensing in package.json, due to SPDX's compound expression syntax. Run npm help package.json for details.
• npm will warn you if the package.json for your project is either missing a "license" field, or if the value of that field isn't a valid SPDX expression (pro tip: "BSD" becomes "BSD-2-Clause" in SPDX (unless you really want one of its variants); "MIT" and "ISC" are fine as-is; the full list is its own package).
• npm init now demands that you use a valid SPDX expression when using it interactively (pro tip: I mostly use npm init -y, having previously run npm config set init.license=MIT / npm config set init.author.email=foo / npm config set init.author.name=me).
• The documentation for package.json has been updated to tell you how to use the "license" field properly with SPDX.

In general, this shouldn't be a big deal for anybody other than people trying to run their own automated license validators, but in the long run, if everybody switches to this format, many people's lives will be made much simpler. I think this is an important improvement for npm and am very thankful to Kyle for taking the lead on this. Also, even if you think all of this is completely stupid, just choose a license anyway. Future you will thank past you someday, unless you are djb, in which case you are djb, and more power to you.

• 8669f7d #8179 Document how to use SPDX in license stanzas in package.json, including how to migrate from old busted license declaration arrays to fancy new compound-license clauses. (@kemitchell)
• 98ad98c #8197 init-package-json@1.5.0 Ensure that packages bootstrapped with npm init use an SPDX-compliant license expression. (@kemitchell)
• 2ad3905 #8197 normalize-package-data@2.1.0: Warn when a package is missing a license declaration, or using a license expression that isn't valid SPDX. (@kemitchell)
• 127bb73 #8197 tar@2.1.1: Switch from BSD to ISC for license, where the latter is valid SPDX. (@othiym23)
• e9a933a #8197 once@1.3.2: Switch from BSD to ISC for license, where the latter is valid SPDX. (@othiym23)
• 412401f #8197 semver@4.3.4: Switch from BSD to ISC for license, where the latter is valid SPDX. (@othiym23)

As a corollary to the previous changes, I've put some work into making npm install spew out fewer pointless warnings about missing values in transitive dependencies. From now on, npm will only warn you about missing READMEs, license fields, and the like for top-level projects (including packages you directly install into your application, but we may relax that eventually).

Practically nobody liked having those warnings displayed for child dependencies, for the simple reason that there was very little that anybody could do about those warnings, unless they happened to be the maintainers of those dependencies themselves. Since many, many projects don't have SPDX-compliant licenses, the number of warnings reached a level where they ran the risk of turning into a block of visual noise that developers (read: me, and probably you) would ignore forever.

So I fixed it. If you still want to see the messages about child dependencies, they're still there, but have been pushed down a logging level to info. You can display them by running npm install -d or npm install --loglevel=info.

• eb18245 Only warn on normalization errors for top-level dependencies. Transitive dependency validation warnings are logged at info level. (@othiym23)

BUG FIXES

• e40e809 tap@1.0.1: TAP: The Next Generation. Fix up many tests to they work properly with the new major version of node-tap. Look at all the colors! (@isaacs)
• f9314e9 nock@1.9.0: Minor tweaks and bug fixes. (@pgte)
• 45c2b1a #8187 npm ls wasn't properly recognizing dependencies installed from GitHub repositories as git dependencies, and so wasn't displaying them as such. (@zornme)
• 1ab57c3 In some cases, npm help was using something that looked like a regular expression where a glob pattern should be used, and vice versa. (@isaacs)