Skip to content

Latest commit

 

History

History
1197 lines (1033 loc) · 59 KB

CHANGELOG.md

File metadata and controls

1197 lines (1033 loc) · 59 KB
Raw

v6.4.1 (2018-08-22):

BUGFIXES

  • 4bd40f543 #42 Prevent blowing up on malformed responses from the npm audit endpoint, such as with third-party registries. (@framp)
  • 0e576f0aa #46 Fix NO_PROXY support by renaming npm-side config to --noproxy. The environment variable should still work. (@SneakyFish5)
  • d8e811d6a #33 Disable update-notifier checks when a CI environment is detected. (@Sibiraj-S)
  • 1bc5b8cea #47 Fix issue where postpack scripts would break if pack was used with --dry-run. (@larsgw)

DEPENDENCY BUMPS

DOCUMENTATION

v6.4.0 (2018-08-09):

NEW FEATURES

  • 6e9f04b0b npm/cli#8 Search for authentication token defined by environment variables by preventing the translation layer from env variable to npm option from breaking :_authToken. (@mkhl)
  • 84bfd23e7 npm/cli#35 Stop filtering out non-IPv4 addresses from local-addrs, making npm actually use IPv6 addresses when it must. (@valentin2105)
  • 792c8c709 npm/cli#31 configurable audit level for non-zero exit npm audit currently exits with exit code 1 if any vulnerabilities are found of any level. Add a flag of --audit-level to npm audit to allow it to pass if only vulnerabilities below a certain level are found. Example: npm audit --audit-level=high will exit with 0 if only low or moderate level vulns are detected. (@lennym)

BUGFIXES

DEPENDENCY UPDATES

A very special dependency update event! Since the release of [email protected], an awkward version conflict that was preventing request from begin flattened was resolved. This means two things:

  1. We've cut down the npm tarball size by another 200kb, to 4.6MB
  2. npm audit now shows no vulnerabilities for npm itself!

Thanks, @rvagg!

DOCUMENTATION

v6.3.0 (2018-08-01):

This is basically the same as the prerelease, but two dependencies have been bumped due to bugs that had been around for a while.

v6.3.0-next.0 (2018-07-25):

NEW FEATURES

  • ad0dd226f npm/cli#26 npm version now supports a --preid option to specify the preid for prereleases. For example, npm version premajor --preid rc will tag a version like 2.0.0-rc.0. (@dwilches)

MESSAGING IMPROVEMENTS

  • c1dad1e99 npm/cli#6 Make npm audit fix message provide better instructions for vulnerabilities that require manual review. (@bradsk88)
  • 15c1130fe Fix missing colon next to tarball url in new npm view output. (@zkat)
  • 21cf0ab68 npm/cli#24 Use the defaut OTP explanation everywhere except when the context is "OTP-aware" (like when setting double-authentication). This improves the overall CLI messaging when prompting for an OTP code. (@jdeniau)

MISC

DOCUMENTATION

v6.2.0 (2018-07-13):

In case you missed it, we moved!. We look forward to seeing future PRs landing in npm/cli in the future, and we'll be chatting with you all in npm.community. Go check it out!

This final release of [email protected] includes a couple of features that weren't quite ready on time but that we'd still like to include. Enjoy!

FEATURES

  • 244b18380 #20554 Add support for tab-separated output for npm audit data with the --parseable flag. (@luislobo)
  • 7984206e2 #12697 Add new sign-git-commit config to control whether the git commit itself gets signed, or just the tag (which is the default). (@tribou)

FIXES

DEPENDENCY BUMPS

DOCS

v6.2.0-next.1 (2018-07-05):

This is a quick patch to the release to fix an issue that was preventing users from installing npm@next.

  • ecdcbd745 #21129 Remove postinstall script that depended on source files, thus preventing npm@next from being installable from the registry. (@zkat)

v6.2.0-next.0 (2018-06-28):

NEW FEATURES

  • ce0793358 #20750 You can now disable the update notifier entirely by using --no-update-notifier or setting it in your config with npm config set update-notifier false. (@travi)
  • d2ad776f6 #20879 When npm run-script <script> fails due to a typo or missing script, npm will now do a "did you mean?..." for scripts that do exist. (@watilde)

BUGFIXES

  • 8f033d72d #20948 Fix the regular expression matching in xcode_emulation in node-gyp to also handle version numbers with multiple-digit major versions which would otherwise break under use of XCode 10. (@Trott)
  • c8ba7573a Stop trying to hoist/dedupe bundles dependencies. (@iarna)
  • cd698f068 #20762 Add synopsis to brief help for npm audit and suppress trailing newline. (@wyardley)
  • 6808ee3bd #20881 Exclude /.github directory from npm tarball. (@styfle)
  • 177cbb476 #21105 Add suggestion to use a temporary cache instead of npm cache clear --force. (@karanjthakkar)

DOCS

DEPENDENCY SHUFFLE!

We did some reshuffling and moving around of npm's own dependencies. This significantly reduces the total bundle size of the npm pack, from 8MB to 4.8MB for the distributed tarball! We also moved around what we actually commit to the repo as far as devDeps go.

DEPENDENCIES

v6.1.0 (2018-05-17):

FIX WRITE AFTER END ERROR

First introduced in 5.8.0, this finally puts to bed errors where you would occasionally see Error: write after end at MiniPass.write.

DETECT CHANGES IN GIT SPECIFIERS

  • 0e1726c03 We can now determine if the commitid of a git dependency in the lockfile is derived from the specifier in the package.json and if it isn't we now trigger an update for it. (@iarna)

OTHER BUGS

  • 442d2484f 2f0c88351 631d30a34 When requesting the update of a direct dependency that was also a transitive dependency to a version incompatible with the transitive requirement and you had a lock-file but did not have a node_modules folder then npm would fail to provide a new copy of the transitive dependency, resulting in an invalid lock-file that could not self heal. (@iarna)
  • be5dd0f49 #20715 Cleanup output of npm ci summary report. (@legodude17)
  • 98ffe4adb Node.js now has a test that scans for things that look like conflict markers in source code. This was triggering false positives on a fixture in a test of npm's ability to heal lockfiles with conflicts in them. (@iarna)

DEPENDENCY UPDATES

v6.1.0-next.0 (2018-05-17):

Look at that! A feature bump! npm@6 was super-exciting not just because it used a bigger number than ever before, but also because it included a super shiny new command: npm audit. Well, we've kept working on it since then and have some really nice improvements for it. You can expect more of them, and the occasional fix, in the next few releases as more users start playing with it and we get more feedback about what y'all would like to see from something like this.

I, for one, have started running it (and the new subcommand...) in all my projects, and it's one of those things that I don't know how I ever functioned -without- it! This will make a world of difference to so many people as far as making the npm ecosystem a higher-quality, safer commons for all of us.

This is also a good time to remind y'all that we have a new RFCs repository, along with a new process for them. This repo is open to anyone's RFCs, and has already received some great ideas about where we can take the CLI (and, to a certain extent, the registry). It's a great place to get feedback, and completely replaces feature requests in the main repo, so we won't be accepting feature requests there at all anymore. Check it out if you have something you'd like to suggest, or if you want to keep track of what the future might look like!

NEW FEATURE: npm audit fix

This is the biggie with this release! npm audit fix does exactly what it says on the tin. It takes all the actionable reports from your npm audit and runs the installs automatically for you, so you don't have to try to do all that mechanical work yourself!

Note that by default, npm audit fix will stick to semver-compatible changes, so you should be able to safely run it on most projects and carry on with your day without having to track down what breaking changes were included. If you want your (toplevel) dependencies to accept semver-major bumps as well, you can use npm audit fix --force and it'll toss those in, as well. Since it's running the npm installer under the hood, it also supports --production and --only=dev flags, as well as things like --dry-run, --json, and --package-lock-only, if you want more control over what it does.

Give it a whirl and tell us what you think! See npm help audit for full docs!

  • 3800a660d Add npm audit fix subcommand to automatically fix detected vulnerabilities. (@zkat)

OTHER NEW audit FEATURES

  • 1854b1c7f #20568 Add support for npm audit --json to print the report in JSON format. (@finnp)
  • 85b86169d #20570 Include number of audited packages in npm install summary output. (@zkat)
  • 957cbe275 [email protected]: Overhaul audit install and detail output format. The new format is terser and fits more closely into the visual style of the CLI, while still providing you with the important bits of information you need. They also include a bit more detail on the footer about what actions you can take! (@zkat)

NEW FEATURE: GIT DEPS AND npm init <pkg>!

Another exciting change that came with npm@6 was the new npm init command that allows for community-authored generators. That means you can, for example, do npm init react-app and it'll one-off download, install, and run create-react-app for you, without requiring or keeping around any global installs. That is, it basically just calls out to npx.

The first version of this command only really supported registry dependencies, but now, @jdalton went ahead and extended this feature so you can use hosted git dependencies, and their shorthands.

So go ahead and do npm init facebook/create-react-app and it'll grab the package from the github repo now! Or you can use it with a private github repository to maintain your organizational scaffolding tools or whatnot. ✨

BUGFIXES

DOCUMENTATION

DEPENDENCY BUMPS

v6.0.1 (2018-05-09):

AUDIT SHOULDN'T WAIT FOREVER

This will likely be reduced further with the goal that the audit process shouldn't noticibly slow down your builds regardless of your network situation.

Looking forward

We're still a way from having node@11, so now's a good time to ensure we don't warn about being used with it.

v6.0.1-next.0 (2018-05-03):

CTRL-C OUT DURING PACKAGE EXTRACTION AS MUCH AS YOU WANT!

SHRONKWRAPS AND LACKFILES

If a published modules had legacy npm-shrinkwrap.json we were saving ordinary registry dependencies (name@version) to your package-lock.json as https:// URLs instead of versions.

  • 89102c0d9 When saving the lock-file compute how the dependency is being required instead of using _resolved in the package.json. This fixes the bug that was converting registry dependencies into https:// dependencies. (@iarna)
  • 676f1239a When encountering a https:// URL in our lockfiles that point at our default registry, extract the version and use them as registry dependencies. This lets us heal package-lock.json files produced by 6.0.0 (@iarna)

AUDIT AUDIT EVERYWHERE

You can't use it quite yet, but we do have a few last moment patches to npm audit to make it even better when it is turned on!

  • b2e4f48f5 Make sure we hide stream errors on background audit submissions. Previously some classes of error could end up being displayed (harmlessly) during installs. (@iarna)
  • 1fe0c7fea Include session and scope in requests (as we do in other requests to the registry). (@iarna)
  • d04656461 Exit with non-zero status when vulnerabilities are found. So you can have npm audit as a test or prepublish step! (@iarna)
  • fcdbcbacc Verify lockfile integrity before running. You'd get an error either way, but this way it's faster and can give you more concrete instructions on how to fix it. (@iarna)
  • 2ac8edd42 Refuse to run in global mode. Audits require a lockfile and globals don't have one. Yet. (@iarna)

DOCUMENTATION IMPROVEMENTS

DEPENDENCY UPDATES

v6.0.0 (2018-04-20):

Hey y'all! Here's another npm@6 release -- with node@10 around the corner, this might well be the last prerelease before we tag 6.0.0! There's two major features included with this release, along with a few miscellaneous fixes and changes.

EXTENDED npm init SCAFFOLDING

Thanks to the wonderful efforts of @jdalton of lodash fame, npm init can now be used to invoke custom scaffolding tools!

You can now do things like npm init react-app or npm init esm to scaffold an npm package by running create-react-app and create-esm, respectively. This also adds an npm create alias, to correspond to Yarn's yarn create feature, which inspired this.

DEPENDENCY AUDITING

This version of npm adds a new command, npm audit, which will run a security audit of your project's dependency tree and notify you about any actions you may need to take.

The registry-side services required for this command to work will be available on the main npm registry in the coming weeks. Until then, you won't get much out of trying to use this on the CLI.

As part of this change, the npm CLI now sends scrubbed and cryptographically anonymized metadata about your dependency tree to your configured registry, to allow notifying you about the existence of critical security flaws. For details about how the CLI protects your privacy when it shares this metadata, see npm help audit, or read the docs for npm audit online. You can disable this altogether by doing npm config set audit false, but will no longer benefit from the service.

MORE package-lock.json FORMAT CHANGES?!

  • 820f74ae2 #20384 Add from field back into package-lock for git dependencies. This will give npm the information it needs to figure out whether git deps are valid, specially when running with legacy install metadata or in --package-lock-only mode when there's no node_modules. This should help remove a significant amount of git-related churn on the lock-file. (@zkat)

BUGFIXES

  • 9d5d0a18a #20358 npm install-test (aka npm it) will no longer generate package-lock.json when running with --no-package-lock or package-lock=false. (@raymondfeng)
  • e4ed976e2 2facb35fb 9c1eb945b #20390 Fix a scenario where a git dependency had a comittish associated with it that was not a complete commitid. npm would never consider that entry in the package.json as matching the entry in the package-lock.json and this resulted in inappropriate pruning or reinstallation of git dependencies. This has been addressed in two ways, first, the addition of the from field as described in #20384 means we can exactly match the package.json. Second, when that's missing (when working with older package-lock.json files), we assume that the match is ok. (If it's not, we'll fix it up when a real installation is done.) (@iarna)

DEPENDENCIES

DOCS

v6.0.0-next.1 (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