#npm5

[npmjs]

The new npm CLI: a year in review; or, what you may have missed!

First published just under a year ago, npm@5 has probably seen the fastest rate in major changes of any prior npm version. Even if you’ve been following us closely, you probably still haven’t been able to keep up with everything that’s been going on with npm@5.

With npm@6.0.0 getting tagged as latest this week, we thought it would be a good idea to summarize all the changes that have happened since npm@5.0.0 was first tagged — and what you can expect to get in one upgrade when you first install npm@6.0.0!

Speeeeeeeed

This one’s first because it’s the most noticeable change for anyone doing the initial switch. npm is now between 4x and 17x faster than npm@4, especially in CI settings. This means developers can iterate on their changes faster, share their changes faster, and spend less time waiting between pushing a new build and continuing deployment. These sorts of speed differences are not just about making existing things fast, either—they’re about opening doors to entire new opportunities and allowing our users to scale projects beyond what they could do before.

We’ll continue to improve performance—both the CLI and registry teams are dedicated to getting you all that code as fast as your hardware allows it.

package-lock.json and automatic conflict resolution

Along with the speed change, you might have noticed a new file in your git repositories. package-lock.json is a so-called “lock file” that saves information about your node_modules/ tree since you last edited your dependencies. Even though it’s a generated file, it’s meant to be committed into git and has a number of benefits, including increased reproducibility across teams, reduced network overhead when installing, and making it easier to debug issues with dependencies.

Because this was such a significant change to the way npm works, initial iterations of package-lock.json were a bit of a bumpy ride, with unexpected changes and platform differences. As of npm@6, your lock file will be stable not just between you and your coworkers on similar platforms, but across operating systems! You can even use npm install --package-lock-only to generate one of these without installing into node_modules/.

Some folks faced issues when using package-lock.json that led to inscrutable git conflicts. As of npm@5.7 (and, by extension, npm@6), npm will now automatically resolve package-lock conflicts when you run npm install during a conflicted state. To make this experience even smoother, we’ve released npm-merge-driver, which lets you do all the rebasing and merging and other git backflips. You can get started with the merge driver by doing $ npx npm-merge-driver install -g one time. After that, all your future merge and rebase conflicts in any git repo will be resolved in the background.

Those of you who used package-lock.json throughout the npm@5 release line will see a big git diff next time you do an npm install with npm@6: the requires field is changing its format slightly, and we’re adding a new from field to locked git dependences (if you use those) but you should not see this happen again if you and your team are all on npm@6 or later.

npx

What’s that npx thing we mentioned? Why, it’s the npm package runner! npm@5.3 introduced a new workflow tool included with npm itself. npx solves a lot of specific problems, but its overall purpose is making the experience of working with npm-based CLI tools easy, smooth, and seamless!

npx can actually do a lot of different things, but the biggest benefits are:

You can run project-local binaries with it. That means you don’t need to install things like grunt-cli, gulp, bower, and tsc globally—you can install them as devDependencies and use npx to run the local versions without hassle (for example, $ npm i -D standard && npx standard).

You can do one-off, temporary installs of command line utilities that you run rarely, such as generators: $ npx create-react-app.

You can easily try different versions of these tools with a single install if you need to compare them: $ npx standard@8 && npx standard@10.

You can even install the shell auto-fallback to not even have to write $ npx ... in many cases.

npx has already made a huge difference in the daily workflow of many of our users. Have you tried it yet?

npm ci

Thanks to the new package-lock.json feature, we were able to add a cool new command in npm@5.7.0: npm ci! This added a second installer to the npm CLI that takes advantage of projects with package-lock.json files in order to rapidly extract to node_modules/. It skips a lot of the interactivity and human-oriented checks that npm install does, and even makes it so that any inconsistencies trigger errors, rather than having the npm install command fix them for you. npm ci, as the name implies, is meant primarily for use in Continuous Integration/Continuous Deployment situations where you want fast installs that give you early warnings about potential errors. npm ci is about 2–3x faster than a regular npm install.

Finally, as with npm it, there’s now an npm cit for doing an npm ci install + npm test in a single command.

Two-factor authentication and token management

Last October, npm introduced two-factor authentication for a number of account-related actions, including publishing and dist-tag management. Roughly 9 billion weekly downloads—about 43% of downloads—now involve packages that were published by 2fa-protected accounts. That’s amazing news for the overall security of the ecosystem.

As part of that release, we also included the ability to create “read-only” tokens, filter tokens by CIDR, and manually manage your active tokens through the CLI and the website.

Brand new cache and offline installs

npm@5 introduced a completely new system cache for package downloads, replacing the older, buggier, and slower implementation. It was built on top of a standalone library, cacache, and was designed to work closely with the new package-lock.json format by enabling content-addressable storage of package data. This allows it to do much faster lookups of tarball data. It also allows npm to verify your package data on every single install, so you can always trust that what comes out of the registry or the cache is exactly the data you expect it to be.

This process also upgraded our shasum infrastructure to support Subresource Integrity, with new tarballs being published with sha512, instead of the now-insecure sha1 algorithm. This method also makes it much easier to upgrade our infrastructure once faster and better cryptographic hashing algorithms become available in Node.js.

Finally, the new cache architecture enabled a much-awaited npm feature: seamless offline installation! If you don’t have network access or can’t reach the registry for some reason, npm will automatically install from your cache without the need for any extra flags or preparation. Just keep a warm cache and go ahead and do your work on a plane or while you’re disconnected from the network to preserve bandwidth. If you’re on a functional but slow connection, you can even use the new --prefer-offline flag to opt into stale data in exchange for minimal network hits.

Reproducible builds

npm ci and lock files aren’t the only exciting feature for devops folks! As part of npm@5, Isaac completely rewrote node-tar, which is a huge part of the recent performance boost. It also gave us the ability to pack tarballs with pinned file timestamps.

npm can now generate and publish tarballs built at different times on different platforms with identical shasums, enabling reproducible builds!

Keep in mind that you still need to make sure your build run-scripts generate reproducible build artifacts for this to work!

npm publish and npm pack improvements

npm now prints a summary of tarball details whenever you package up an npm project. This summary includes information about the files that you’re including, along with their file sizes (which can help make sure you’re publishing only what you intend), the name and version of the package, and the shasum and integrity for the generated tarball.

In addition, both npm publish and npm pack now support --dry-run and --json flags. With these, you can test that you’re getting what you expect before you actually publish your project. If you’re trying to get reproducible builds working, you can use --dry-run to check that your scripts are generating your published files consistently.

Because npm publish and npm pack both accept any package specifier, you can even use them to test other people’s packages to make sure, for example, that the tarball published to npm actually matches the tagged git version: $ npm pack --dry-run github:zkat/figgy-pudding && npm pack --dry-run figgy-pudding.

You can even hook into the new prepack, pack, and postpack lifecycle scripts along with the new prepare lifecycle to automate this detection as desired.

Better git support

npm has also greatly improved its interaction with git dependencies, adding two major features to git deps:

First, git-based packages with prepare scripts defined will have their devDependencies installed and the prepare script executed before the package tarball for the dependency is packaged and installed. This means that if you want to work off a fork but you want a build step for your library, you can still have that build process! You don’t need to check in built/minified .js directly into git anymore—npm will generate them for you.

Second, npm added semver-range support for git dependencies. Just like you can do $ npm install pkg@^1.2, you can now do npm install github:usr/pkg#semver:^1.2. Semver support will work off branch and tag names, so as long as you keep those up, you’ll be able to use semver with them.

These features should help smooth out the experience for users that are heavily reliant on git dependencies.

npm hooks

npm hooks have been available for a couple of years, but the only way to manage them was through a separate CLI. As of npm@6, you can manage hooks directly with npm itself.

This feature allows you to add webhooks to npm packages, scopes, or users, and have the npm registry post to an external endpoint when related events happen. Hooks can be a great way to integrate npm into your release flow or to get better analytics. Check them out!

file: dependency symlinking

Previously, directory dependencies (that is, what would install if you did $ npm install ../some-pkg), would go through a two-step process: first, they would be packaged into a tarball, as if for publishing, and then that tarball would be installed as a dependency. However, updating that dependency’s code in the future required that you do a full install of it again. That caused some friction for users wanting to work based off local packages or who were working on monorepos.

Now, those dependencies are installed as symlinks, so any changes you make to them will be immediately visible to your package without needing to do a whole new install.

Improved output and usability improvements

npm@6 also includes a number of smaller aesthetic and usability improvements we’ve been incrementally landing in npm:

npm install saves by default

npm install now savess dependency changes by default. You no longer need to remember to add --save before your dependencies get written to package.json (and package-lock.json). This applies to other commands as well, like npm update and npm uninstall.

New npm view output format

Previously, you’d get several screenfuls of colorful JSON output any time you did $ npm view. Now you get this:

You can still access the JSON version by using --json or you can access specific packument fields with $ npm view [...], but the default view is now much easier to view and understand and it includes what we think is the most essential information about the package.

Short install summary

Running npm install in npm@4 would get you a massive amount of tree output. This output made sense when projects were smaller, but it eventually became unreadable for users and took a long time to calculate and print out.

Now, this is all you get when you run npm install on a big project:

We also added the by N contributors section to increase awareness of everyone putting effort into improving the npm ecosystem. You can find out how to give back by running $ npx thanks.

npm update respects latest

The npm update command was a weird creature before: unlike npm install, it would ignore the latest tag and instead install the highest semver-matching version available for that package. Sometimes, these higher versions were intended as prerelease versions and could cause unintentional installs of unstable software.

As of npm@6, $ npm update foo and $ npm install foo will have similar semantics on this front, with the exception that update will limit its install to a version matching the currently-saved semver range for that package.

install and update skip deprecated versions.

Along those lines, if you try and install a package and it has deprecated some of its versions, npm@6 will try to avoid installing the deprecated ones and find other matching versions if possible. Deprecated versions will only be installed if there’s no other way to fulfill the requested version.

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

So, given this example, npm install example@^1 will now install example@1.1.2, whereas before, it would have installed example@1.1.3.

…and more to come!

There’s a lot of very exciting changes coming in 2018! For more info about what we have planned, take a look at this post. 

 We’re working hard this year to continue minimizing friction for JavaScript developers and make the experience of using npm as smooth, seamless, and secure as we can. npm is the largest package ecosystem in the world and continues to grow at an incredible pace—we’re glad to have the opportunity to make that possible and bring JavaScript and web development into the future it deserves!

Watch this space: follow @npmjs on Twitter for release updates and subscribe to our newsletter!

[ifaabeyo]

at Queens, New York https://www.instagram.com/p/CCM6T5-npM5/?igshid=1im6s86s4a7p2

[vuejs2]

RT @maybekatz: In light of recent events, I've decided it's time to start looking for my next role! I'm an open source dev and I've been the lead dev for a while on the npm CLI that so many of you probably use. I was the one who wrote a lot of npm5! Hit me up in DMs or replies!

[webpacknews]

RT @maybekatz: In light of recent events, I've decided it's time to start looking for my next role! I'm an open source dev and I've been the lead dev for a while on the npm CLI that so many of you probably use. I was the one who wrote a lot of npm5! Hit me up in DMs or replies!

[123blacklights-blog]

123blacklights provides a Pair of Numark NPM5 Active  monitors only $99 a pair! More Info:https://www.123blacklights.com/numark-npm5-2773

[danyllr]

RT @maybekatz: I thought this might be cool so I hacked up a little prototype/proof-of-concept. Future #npm5 feature: auto-instal… https://t.co/tpB0fCpppj

I thought this might be cool so I hacked up a little prototype/proof-of-concept. Future #npm5 feature: auto-install missing deps? http://pic.twitter.com/BnE3Ae9JQi

— Internal API Crimes (@maybekatz) July 1, 2017

from Twitter https://twitter.com/d4nyll July 02, 2017 at 05:34AM via IFTTT

[loudmonitor]

Numark NPM5 Studio Monitor System - Loud Monitor

Numark NPM5 Studio Monitor System

Rating: List Price: Discount: 0.00 Sale Price: (as of 12/31/1969 16:00 PST)Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply to the purchase of this product.. Check Price Right Now! Availability: Free Shipping: unspecified

Product Description

Details

No features available.

[ryrychu]

View this post on Instagram

A post shared by Ryan Empeno (@src_ryry)

Ugh I'm loving this setup. Here's a quick mashup 😎 Rump Shaker by Wreckx-N-Effect X 93 Til Infinity by Souls of Mischief #numark #npm5 #mixtrackpro2 #soulrebelz

[npmjs]

v5.9.0-next.0

Coming to you this week are a fancy new package view, pack/publish previews and a handful of bug fixes! Let's get right in!

NEW PACKAGE VIEW

There's a new npm view in town. You might it as npm info or npm show. The new output gives you a nicely summarized view that for most packages fits on one screen. If you ask it for --json you'll still get the same results, so your scripts should still work fine.

143cdbf13 #19910 Add humanized default view. (@zkat)

ca84be91c #19910 tiny-relative-date@1.3.0 (@zkat)

9a5807c4f #19910 cli-columns@3.1.2 (@zkat)

23b4a4fac #19910 byte-size@4.0.2

PACK AND PUBLISH PREVIEWS

The npm pack and npm publish commands print out a summary of the files included in the package. They also both now take the --dry-run flag, so you can double check your .npmignore settings before doing a publish.

116e9d827 #19908 Add package previews to pack and publish. Also add --dry-run and --json flags. (@zkat)

MERGE CONFLICT, SMERGE CONFLICT

If you resolve a package-lock.json merge conflict with npm install we now suggest you setup a merge driver to handle these automatically for you. If you're reading this and you'd like to set it up now, run:

npx npm-merge-driver install -g

5ebe99719 #20071 suggest installing the merge driver (@zkat)

MISC BITS

a05e27b71 Going forward, record requested ranges not versions in the package-lock. (@iarna)

f721eec59 Add 10 to Node.js supported version list. It's not out yet, but soon my pretties... (@iarna)

DEPENDENCY UPDATES

40aabb94e libcipm@1.6.1: Fix bugs on docker and with some prepare scripts and npm ci. Fix a bug where script hooks wouldn't be called with npm ci. Fix a bug where npm ci and --prefix weren't compatible. (@isaacseymour) (@umarov) (@mikeshirov) (@billjanitsch)

a85372e67 tar@4.4.1: Switch to safe-buffer and Buffer.from. (@isaacs) (@ChALkeR)

588eabd23 lru-cache@4.1.2

07f27ee89 qrcode-terminal@0.12.0

01e4e29bc request@2.85.0

344ba8819 worker-farm@1.6.0

dc6df1bc4 validate-npm-package-license@3.0.3

97a976696 ssri@5.3.0

9b629d0c6 query-string@5.1.1

[npmjs]

v5.0.2 (2017-06-02)

Here's another patch release, soon after the other!

This particular release includes a slew of fixes to npm's git support, which was causing some issues for a chunk of people, specially those who were using self-hosted/Enterprise repos. All of those should be back in working condition now.

There's another shiny thing you might wanna know about: npm has a Canary release now! The npm5 experiment we did during our beta proved to be incredibly successful: users were able to have a tight feedback loop between reports and getting the bugfixes they needed, and the CLI team was able to roll out experimental patches and have the community try them out right away. So we want to keep doing that.

From now on, you'll be able to install the 'npm canary' with npm i -g npmc. This release will be a separate binary (npmc. Because canary. Get it?), which will update independently of the main CLI. Most of the time, this will track release-next or something close to it. We might occasionally toss experimental branches in there to see if our more adventurous users run into anything interesting with it. For example, the current canary (npmc@5.0.1-canary.6) includes an experimental multiproc branch that parallelizes tarball extraction across multiple processes.

If you find any issues while running the canary version, please report them and let us know it came from npmc! It would be tremendously helpful, and finding things early is a huge reason to have it there. Happy hacking!

A NOTE ABOUT THE ISSUE TRACKER

Just a heads up: We're preparing to do a massive cleanup of the issue tracker. It's been a long time since it was something we could really keep up with, and we didn't have a process for dealing with it that could actually be sustainable.

We're still sussing the details out, and we'll talk about it more when we're about to do it, but the plan is essentially to close old, abandoned issues and start over. We will also add some automation around issue management so that things that we can't keep up with don't just stay around forever.

Stay tuned!

GIT YOLO

1f26e9567 pacote@2.7.27: Fixes installing committishes that look like semver, even though they're not using the required #semver: syntax. (@zkat)

85ea1e0b9 npm-package-arg@5.1.1: This includes the npa git-parsing patch to make it so non-hosted SCP-style identifiers are correctly handled. Previously, npa would mangle them (even though hosted-git-info is doing the right thing for them). (@zkat)

COOL NEW OUTPUT

The new summary output has been really well received! One downside that reared its head as more people used it, though, is that it doesn't really tell you anything about the toplevel versions it installed. So, if you did npm i -g foo, it would just say "added 1 package". This patch by @rmg keeps things concise while still telling you what you got! So now, you'll see something like this:

$ npm i -g foo bar + foo@1.2.3 + bar@3.2.1 added 234 packages in .005ms

362f9fd5b #16899 For every package that is given as an argument to install, print the name and version that was actually installed. (@rmg)

OTHER BUGFIXES

a47593a98 #16835 Fix a crash while installing with --no-shrinkwrap. (@jacknagel)

DOC UPATES

89e0cb816 #16818 Fixes a spelling error in the docs. Because the CLI team has trouble spelling "package", I guess. (@ankon)

c01fbc46e #16895 Remove --save from npm init instructions, since it's now the default. (@jhwohlgemuth)

80c42d218 Guard against cycles when inflating bundles, as symlinks are bundles now. (@iarna)

7fe7f8665 #16674 Write the builtin config for npmc, not just npm. This is hardcoded for npm self-installations and is needed for Canary to work right. (@zkat)

DEP UPDATES

63df4fcdd #16894 node-gyp@3.6.2: Fixes an issue parsing SDK versions on Windows, among other things. (@refack)

5bb15c3c4 read-package-tree@5.1.6: Fixes some racyness while reading the tree. (@iarna)

a6f7a52e7 aproba@1.1.2: Remove nested function declaration for speed up (@mikesherov)

[npmjs]

v5.0.4 (2017-06-13)

Hey y'all. This is another minor patch release with a variety of little fixes we've been accumulating~

f0a37ace9 Fix npm doctor when hitting registries without ping. (@zkat)

64f0105e8 Fix invalid format error when setting cache-related headers. ([@Kat Marchán](https://github.com/Kat Marchán))

d2969c80e Fix spurious EINTEGRITY issue. (@zkat)

800cb2b4e #17076 Use legacy from field to improve upgrade experience from legacy shrinkwraps and installs. (@zkat)

4100d47ea #17007 Restore loose semver parsing to match older npm behavior when running into invalid semver ranges in dependencies. (@zkat)

35316cce2 #17005 Emulate npm@4's behavior of simply marking the peerDep as invalid, instead of crashing. (@zkat)

e7e8ee5c5 #16937 Workaround for separate bug where requested was somehow null. (@forivall)

2d9629bb2 Better logging output for git errors. (@zkat)

2235aea73 More scp-url fixes: parsing only worked correctly when a committish was present. (@zkat)

80c33cf5e Standardize package permissions on tarball extraction, instead of using perms from the tarball. This matches previous npm behavior and fixes a number of incompatibilities in the wild. (@zkat)

2b1e40efb Limit shallow cloning to hosts which are known to support it. (@zkat)

[npmjs]

v5.0.0

Wowowowowow npm@5!

This release marks months of hard work for the young, scrappy, and hungry CLI team, and includes some changes we've been hoping to do for literally years. npm@5 takes npm a pretty big step forward, significantly improving its performance in almost all common situations, fixing a bunch of old errors due to the architecture, and just generally making it more robust and fault-tolerant. It comes with changes to make life easier for people doing monorepos, for users who want consistency/security guarantees, and brings semver support to git dependencies. See below for all the deets!

Breaking Changes

Existing npm caches will no longer be used: you will have to redownload any cached packages. There is no tool or intention to reuse old caches. (#15666)

npm install ./packages/subdir will now create a symlink instead of a regular installation. file://path/to/tarball.tgz will not change -- only directories are symlinked. (#15900)

npm will now scold you if you capitalize its name. seriously it will fight you.

npm will --save by default now. Additionally, package-lock.json will be automatically created unless an npm-shrinkwrap.json exists. (#15666)

Git dependencies support semver through user/repo#semver:^1.2.3 (#15308) (#15666) (@sankethkatta)

Git dependencies with prepare scripts will have their devDependencies installed, and npm install run in their directory before being packed.

npm cache commands have been rewritten and don't really work anything like they did before. (#15666)

--cache-min and --cache-max have been deprecated. (#15666)

Running npm while offline will no longer insist on retrying network requests. npm will now immediately fall back to cache if possible, or fail. (#15666)

package locks no longer exclude optionalDependencies that failed to build. This means package-lock.json and npm-shrinkwrap.json should now be cross-platform. (#15900)

If you generated your package lock against registry A, and you switch to registry B, npm will now try to install the packages from registry B, instead of A. If you want to use different registries for different packages, use scope-specific registries (npm config set @myscope:registry=https://myownregist.ry/packages/). Different registries for different unscoped packages are not supported anymore.

Shrinkwrap and package-lock no longer warn and exit without saving the lockfile.

Local tarballs can now only be installed if they have a file extensions .tar, .tar.gz, or .tgz.

A new loglevel, notice, has been added and set as default.

One binary to rule them all: ./cli.js has been removed in favor of ./bin/npm-cli.js. In case you were doing something with ./cli.js itself. (#12096) (@watilde)

Stub file removed (#16204) (@watilde)

The "extremely legacy" _token couchToken has been removed. (#12986)

Feature Summary

Installer changes

A new, standardised lockfile feature meant for cross-package-manager compatibility (package-lock.json), and a new format and semantics for shrinkwrap. (#16441)

--save is no longer necessary. All installs will be saved by default. You can prevent saving with --no-save. Installing optional and dev deps is unchanged: use -D/--save-dev and -O/--save-optional if you want them saved into those fields instead. Note that since npm@3, npm will automatically update npm-shrinkwrap.json when you save: this will also be true for package-lock.json. (#15666)

Installing a package directory now ends up creating a symlink and does the Right Thing™ as far as saving to and installing from the package lock goes. If you have a monorepo, this might make things much easier to work with, and probably a lot faster too. 😁 (#15900)

Project-level (toplevel) preinstall scripts now run before anything else, and can modify node_modules before the CLI reads it.

Two new scripts have been added, prepack and postpack, which will run on both npm pack and npm publish, but NOT on npm install (without arguments). Combined with the fact that prepublishOnly is run before the tarball is generated, this should round out the general story as far as putzing around with your code before publication.

Git dependencies with prepare scripts will now have their devDependencies installed, and their prepare script executed as if under npm pack.

Git dependencies now support semver-based matching: npm install git://github.com/npm/npm#semver:^5 (#15308, #15666)

node-gyp now supports node-gyp.cmd on Windows (#14568)

npm no longer blasts your screen with the whole installed tree. Instead, you'll see a summary report of the install that is much kinder on your shell real-estate. Specially for large projects. (#15914):

$ npm install npm added 125, removed 32, updated 148 and moved 5 packages in 5.032s. $

--parseable and --json now work more consistently across various commands, particularly install and ls.

Indentation is now detected and preserved for package.json, package-lock.json, and npm-shrinkwrap.json. If the package lock is missing, it will default to package.json's current indentation.

Publishing

New publishes will now include both sha512 and sha1 checksums. Versions of npm from 5 onwards will use the strongest algorithm available to verify downloads. npm/npm-registry-client#157

Cache Rewrite!

We've been talking about rewriting the cache for a loooong time. So here it is. Lots of exciting stuff ahead. The rewrite will also enable some exciting future features, but we'll talk about those when they're actually in the works. #15666 is the main PR for all these changes. Additional PRs/commits are linked inline.

Package metadata, package download, and caching infrastructure replaced.

It's a bit faster. Hopefully it will be noticeable. 🤔

With the shrinkwrap and package-lock changes, tarballs will be looked up in the cache by content address (and verified with it).

Corrupted cache entries will automatically be removed and re-fetched on integrity check failure.

npm CLI now supports tarball hashes with any hash function supported by Node.js. That is, it will use sha512 for tarballs from registries that send a sha512 checksum as the tarball hash. Publishing with sha512 is added by npm/npm-registry-client#157 and may be backfilled by the registry for older entries.

Remote tarball requests are now cached. This means that even if you're missing the integrity field in your shrinkwrap or package-lock, npm will be able to install from the cache.

Downloads for large packages are streamed in and out of disk. npm is now able to install packages of """any""" size without running out of memory. Support for publishing them is pending (due to registry limitations).

Automatic fallback-to-offline mode. npm will seamlessly use your cache if you are offline, or if you lose access to a particular registry (for example, if you can no longer access a private npm repo, or if your git host is unavailable).

A new --prefer-offline option will make npm skip any conditional requests (304 checks) for stale cache data, and only hit the network if something is missing from the cache.

A new --prefer-online option that will force npm to revalidate cached data (with 304 checks), ignoring any staleness checks, and refreshing the cache with revalidated, fresh data.

A new --offline option will force npm to use the cache or exit. It will error with an ENOTCACHED code if anything it tries to install isn't already in the cache.

A new npm cache verify command that will garbage collect your cache, reducing disk usage for things you don't need (-handwave-), and will do full integrity verification on both the index and the content. This is also hooked into npm doctor as part of its larger suite of checking tools.

The new cache is very fault tolerant and supports concurrent access.

Multiple npm processes will not corrupt a shared cache.

Corrupted data will not be installed. Data is checked on both insertion and extraction, and treated as if it were missing if found to be corrupted. I will literally bake you a cookie if you manage to corrupt the cache in such a way that you end up with the wrong data in your installation (installer bugs notwithstanding).

npm cache clear is no longer useful for anything except clearing up disk space.

Package metadata is cached separately per registry and package type: you can't have package name conflicts between locally-installed packages, private repo packages, and public repo packages. Identical tarball data will still be shared/deduplicated as long as their hashes match.

HTTP cache-related headers and features are "fully" (lol) supported for both metadata and tarball requests -- if you have your own registry, you can define your own cache settings the CLI will obey!

prepublishOnly now runs before the tarball to publish is created, after prepare has run.

[npmjs]

npm, the npm github issue tracker, and you!

The npm cli GitHub project is one of the most active on all of GitHub. The npm cli team is made up of two people, Rebecca Turner and Kat Marchán. At the time of this writing there are 3,244 open issues in the issue tracker. That's clearly more issue than a team of two can reasonably handle, even with the invaluable help of the community. It's even more untenable when you consider that this team is the team fixing the vast majority of the bugs and implementing new features.

Prior to January of 2017 some effort was made to try work the issue tracker while still working on the cli. That was put aside so that we could focus on npm@5. Ongoing we can not and do not want to continue ignoring the issue tracker. Even with its overwhelming size it's extremely helpful.

So in an attempt to make it serve our team better we're going to begin automatically closing issues that go too long without activity. This reflects the existing reality that older issues are unlikely to get attention. By making this explicit we hope that it will help ensure that issues that are pain points do not disappear into the churn: If our bots close your issue and it's still a problem for you, please open a new version of it.

The initial policies are outlined below. We'll revisit these over time and may adjust some of the numbers. To begin with, we are only considering closing issues that are neither assigned to a team member nor assigned to a milestone. If we do either of those the issue or pull request will stay open.

Issue Type Closed after… Support 3 days Untriaged 7 days Inactive 30 days Inactive PRs 60 days

For issues triaged as support: Issues with no activity for three days will be closed. While we want to give community members an opportuntity to help each other, ultimately this is not the venue for that. You'll likely be better served by joining something like package.community and asking your questions there.

For issues that have not received any triage (no labels): Issues with no activity for seven days will be closed. Ideally all incoming issues would be triaged but in practice this isn't practical. Most of these issues are support issues.

For issues that have all other issues: Issues with no activity for thirty days will be closed. If your issue is closed and it's still a problem for you then we encourage you to open a new issue.

For pull requests: Pull requests with no activity for sixty days will be closed. You are always welcome to open a new pull request (but please rebase on to npm/npm#latest).

[123blacklights-blog]

Pair of Numark monitors only $99 a pair!

More Info:https://www.123blacklights.com/numark-npm5-2772

#chicagodjequipment #djequipment #djlights #djspeakers #djgear #chicagodjlights #chicagodjaudio

[npmjs]

v5.10.0

NEW FEATURES

32ec2f54b #20257 Add shasum and integrity to the new npm view output. (@zkat)

a22153be2 #20126 Add npm cit command that's equivalent of npm ci && npm t that's equivalent of npm it. (@SimenB)

BUG FIXES

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

6eaa860ea Eliminate direct use of new Buffer in npm. While the use of it in npm was safe, there are two other reasons for this change:

Node 10 emits warnings about its use.

Users who require npm as a library (which they definitely should not do) can call the functions that call new Buffer in unsafe ways, if they try really hard.

(@iarna)

85900a294 Starting with 5.8.0 the requires section of the lock-file saved version ranges instead of specific versions. Due to a bug, further actions on the same lock-file would result in the range being switched back to a version. This corrects that, keeping ranges when they appear. (@iarna)

0dffa9c2a 609d6f6e1 08f81aa94 f8b76e076 6d609822d 59d080a22 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)

db846c2d5 #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)

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

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

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

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

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

5d17c87d8 #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)

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

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

155dab2bd Fix a bug where optional status of a dependency was not being saved to the package-lock on the initial install. (@iarna)

8d6a4cafc a0937e9af Ensure that --no-optional does not remove optional dependencies from the lock-file. (@iarna)

DEPENDENCY UPDATES

8baa37551 zkat/cipm#46 libcipm@1.6.2: Detect binding.gyp for default install lifecycle. Let's npm ci work on projects that have their own C code. (@caleblloyd)

323f74242 zkat/json-parse-better-errors#1 json-parse-better-errors@1.0.2 (@Hoishin)

d0cf1f11e readable-stream@2.3.6 (@mcollina)

9e9fdba5e update-notifier@2.4.0 (@sindersorhus)

57fa33870 marked@0.3.1 (@joshbruce)

d2b20d34b #20276 node-gyp@3.6.2

2b5700679 zkat/npx#172 libnpx@10.1.1 (@jdalton)

[npmjs]

v5.7.0

Hey y'all, it's been a while. Expect our release rate to increase back to normal here, as we've got a lot in the pipeline. Right now we've got a bunch of things from folks at npm. In the next release we'll be focusing on user contributions and there are a lot of them queued up!

This release brings a bunch of exciting new features and bug fixes.

PACKAGE-LOCK GIT MERGE CONFLICT RESOLUTION

Allow npm install to fix package-lock.json and npm-shrinkwrap.json files that have merge conflicts in them without your having to edit them. It works in conjunction with npm-merge-driver to entirely eliminate package-lock merge conflicts.

e27674c22 Automatically resolve merge conflicts in lock-files. (@zkat)

NPM CI

The new npm ci command installs from your lock-file ONLY. If your package.json and your lock-file are out of sync then it will report an error.

It works by throwing away your node_modules and recreating it from scratch.

Beyond guaranteeing you that you'll only get what is in your lock-file it's also much faster (2x-10x!) than npm install when you don't start with a node_modules.

As you may take from the name, we expect it to be a big boon to continuous integration environments. We also expect that folks who do production deploys from git tags will see major gains.

5e4de9c99 Add new npm ci installer. (@zkat)

OTHER NEW FEATURES

4d418c21b #19817 Include contributor count in installation summary. (@kemitchell)

17079c2a8 Require password to change email through npm profile. (@iarna)

e7c5d226a 4f5327c05 #19780 Add support for web-based logins. This is not yet available on the registry, however. (@isaacs)

BIG FIXES TO PRUNING

827951590 Handle running npm install package-name with a node_modules containing packages without sufficient metadata to verify their origin. The only way to get install packages like this is to use a non-npm package manager. Previously npm removed any packages that it couldn't verify. Now it will leave them untouched as long as you're not asking for a full install. On a full install they will be reinstalled (but the same versions will be maintained).

This will fix problems for folks who are using a third party package manager to install packages that have postinstall scripts that run npm install. (@iarna)

3b305ee71 Only auto-prune on installs that will create a lock-file. This restores npm@4 compatible behavior when the lock-file is disabled. When using a lock-file npm will continue to remove anything in your node_modules that's not in your lock-file. (@iarna)

cec5be542 Fix bug where npm prune --production would remove dev deps from the lock file. It will now only remove them from node_modules not from your lock file. (@iarna)

857dab03f Fix bug where git dependencies would be removed or reinstalled when installing other dependencies. (@iarna)

BUG FIXES TO TOKENS AND PROFILES

a66e0cd03 For CIDR filtered tokens, allow comma separated CIDR ranges, as documented. Previously you could only pass in multiple cidr ranges with multiple --cidr command line options. (@iarna)

d259ab014 Fix token revocation when an OTP is required. Previously you had to pass it in via --otp. Now it will prompt you for an OTP like other npm token commands. (@iarna)

f8b1f6aec Update token and profile commands to support legacy (username/password) authentication. (The npm registry uses tokens, not username/password pairs, to authenticate commands.) (@iarna)

OTHER BUG FIXES

6954dfc19 Fix a bug where packages would get pushed deeper into the tree when upgrading without an existing copy on disk. Having packages deeper in the tree ordinarily is harmless but is not when peerDependencies are in play. (@iarna)

1ca916a1e Fix bug where when switching from a linked module to a non-linked module, the dependencies of the module wouldn't be installed on the first run of npm install. (@iarna)

8c120ebb2 Fix integrity matching to eliminate spurious EINTEGRITY errors. (@zkat)

94227e15e More consistently make directories using perm and ownership preserving features. (@iarna)

DEPENDENCY UPDATES

364b23c7f f2049f9e7 cacache@10.0.4 (@zkat)

d183d7675 find-npm-prefix@1.0.2: (@iarna)

ffd6ea62c fs-minipass@1.2.5

ee63b8a31 ini@1.3.5 (@isaacs)

6f73f5509 JSONStream@1.3.2 (@dominictarr)

26cd64869 9bc6230cf libcipm@1.3.3 (@zkat)

21a39be42 marked@0.3.1:5 (@joshbruce)

dabdf57b2 mississippi@2.0.0

2594c5867 npm-registry-couchapp@2.7.1 (@iarna)

8abb3f230 osenv@0.1.5 (@isaacs)

11a0b00bd pacote@7.3.3 (@zkat)

9b6bdb2c7 query-string@5.1.0 (@sindresorhus)

d6d17d6b5 readable-stream@2.3.4 (@mcollina)

51370aad5 semver@5.5.0 (@isaacs)

0db14bac7 81da938ab 9999e83f8 ssri@5.2.4 (@zkat)

f526992ab tap@11.1.1 (@isaacs)

be096b409 dc3059522 tar@4.3.3

6b552daac uuid@3.2.1 (@broofa)

8c9011b72 worker-farm@1.5.2 (@rvagg)