Skip to content

Latest commit

 

History

History
267 lines (232 loc) · 13 KB

CHANGELOG.md

File metadata and controls

267 lines (232 loc) · 13 KB

v6.0.0 (2018-04-12):

NEW FEATURES

BUG FIXES

  • 685764308 Fix a bug where OTPs passed in via the commandline would have leading zeros deleted resulted in authentication failures. (@iarna)

  • 8f3faa323 6800f76ff ec90c06c7 825b5d2c6 4785f13fb bd16485f5 Restore the ability to bundle dependencies that are uninstallable from the registry. This also eliminates needless registry lookups for bundled dependencies.

    Fixed a bug where attempting to install a dependency that is bundled inside another module without reinstalling that module would result in ENOENT errors. (@iarna)

  • 429498a8c #20029 Allow packages with non-registry specifiers to follow the fast path that the we use with the lock-file for registry specifiers. This will improve install time especially when operating only on the package-lock (--package-lock-only). (@zkat)

    Fix the a bug where npm i --only=prod could remove development dependencies from lock-file. (@iarna)

  • 834b46ff4 #20122 Improve the update-notifier messaging (borrowing ideas from pnpm) and eliminate false positives. (@zkat)

  • f9de7ef3a #20154 Let version succeed when package-lock.json is gitignored. (@nwoltman)

  • f8ec52073 #20212 Ensure that we only create an etc directory if we are actually going to write files to it. (@buddydvd)

  • ab489b753 #20140 Note in documentation that package-lock.json version gets touched by npm version. (@srl295)

  • 857c2138d #20032 Fix bug where unauthenticated errors would get reported as both 404s and 401s, i.e. npm ERR! 404 Registry returned 401. In these cases the error message will now be much more informative. (@iarna)

  • d2d290bca #20082 Allow optional @ prefix on scope with npm team commands for parity with other commands. (@bcoe)

  • b5babf0a9 #19580 Improve messaging when two-factor authentication is required while publishing. (@jdeniau)

  • 471ee1c5b 0da38b7b4 Fix a bug where optional status of a dependency was not being saved to the package-lock on the initial install. (@iarna)

  • b3f98d8ba 9dea95e31 Ensure that --no-optional does not remove optional dependencies from the lock-file. (@iarna)

MISCELLANEOUS

  • ec6b12099 Exclude all tests from the published version of npm itself. (@iarna)

DEPENDENCY UPDATES

v6.0.0-0 (2018-03-23):

Sometimes major releases are a big splash, sometimes they're something smaller. This is the latter kind. That said, we expect to keep this in release candidate status until Node 10 ships at the end of April. There will likely be a few more features for the 6.0.0 release line between now and then. We do expect to have a bigger one later this year though, so keep an eye out for npm@7!

BREAKING AVOID DEPRECATED

When selecting versions to install, we now avoid deprecated versions if possible. For example:

Module: example
Versions:
1.0.0
1.1.0
1.1.2
1.1.3 (deprecated)
1.2.0 (latest)

If you ask npm to install example@~1.1.0, npm will now give you 1.1.2.

By contrast, if you installed example@~1.1.3 then you'd get 1.1.3, as it's the only version that can match the range.

BREAKING UPDATE AND OUTDATED

When npm install is finding a version to install, it first checks to see if the specifier you requested matches the latest tag. If it doesn't, then it looks for the highest version that does. This means you can do release candidates on tags other than latest and users won't see them unless they ask for them. Promoting them is as easy as setting the latest tag to point at them.

Historically npm update and npm outdated worked differently. They just looked for the most recent thing that matched the semver range, disregarding the latest tag. We're changing it to match npm install's behavior.

PLUS ONE SMALLER PATCH

Technically this is a bug fix, but the change in behavior is enough of an edge case that I held off on bringing it in until a major version.

When we extract a binary and it starts with a shebang (or "hash bang"), that is, something like:

#!/usr/bin/env node

If the file has Windows line endings we strip them off of the first line. The reason for this is that shebangs are only used in Unix-like environments and the files with them can't be run if the shebang has a Windows line ending.

Previously we converted ALL line endings from Windows to Unix. With this patch we only convert the line with the shebang. (Node.js works just fine with either set of line endings.)

BREAKING SUPPORTED NODE VERSIONS

Per our supported Node.js policy, we're dropping support for both Node 4 and Node 7, which are no longer supported by the Node.js project.

DEPENDENCIES