feature request: force install from cache. #2568

Open
dominictarr opened this Issue Jun 26, 2012 · 67 comments

Projects

None yet
npm install module --cache

would behave as if there is not network connection.

this would be very useful when the connection is slow,
and you know the modules you are installing well.

it would also create the possibility for a background process that tails npm
and keeps your cache up to date. making installs super fast!

Owner
isaacs commented Jun 27, 2012

Hm. This used to work as npm install --no-registry, but apparently that's broken now.

Owner
isaacs commented Jun 27, 2012

Oh, you can also set the cache-min config value to something greater than 0, and then nothing younger than that number of seconds will be fetched, ever.

npm install --cache-min 999999 would effectively be what you're asking for.

thanks!

Is no-registry going to be fixed? cache-min still appears to ping the registry to ask what the times are and that's undesirable?

Owner
isaacs commented Jul 11, 2012

Ack, indeed, this was broken with the npm-registry-client refactor. Fixed on 81fa33a.

Cool thanks :-)

Owner
isaacs commented Jul 11, 2012

Also, --no-registry will be fixed on the next npm version (included in node 0.8.3 and 0.9.0)

Contributor

There is no mention of --no-registry in npm help install.

@luk- luk- reopened this Nov 13, 2013
Contributor
luk- commented Nov 13, 2013

This is still broken.

Any word on the status of this flag?

by the way, this works with npmd if you use npmd install foo --offline

I've seen this fail using a command like this:

npm install --no-registry path/to/package.tgz

But this succeeds:

npm install --no-registry --cache path/to/cache/dir

That's perfect for my use case but I don't know if it's how it's intended to work.

This was with version 1.2.18.

@grahamlyons you are using quite an old version of npm. yes, installing from a file path needs to point to a directory.

@grahamlyons in npm v1.3.17, the following fails now:
npm install ejs --no-registry --cache /Users/mike/.npm

As does:
npm install ejs --no-registry
#3691 (comment)

Member
domenic commented Dec 16, 2013

This is in my notes from JSConf EU as something we are worse at than bower. We should make it more reliable to install while offline. But, probably as part of the big ol' cache refactor.

@domenic I'll help if I can :) (I'm trying to refactor sails new to use what npm already provides and avoid reinventing the wheel- just ran into this along the way. Checked out npmd and looks really promising- can't add it to our deps though :\ )

@isaacs Btw-- cache-min works great in 1.3.17, both from the CLI and programmatically (it's a little slower than doing copies, but presumably that's because it's properly checking on descendant dependencies in the modules)

So, for our friends who might be googling this in the future:

Install npm dependencies from cache (i.e. offline, no connection)

Tested in npm v1.3.17

CLI
npm install ejs sails-disk optimist grunt --cache-min 999999999
Programmatically
var npm = require('npm');

var modules = ['ejs', 'grunt', 'sails-disk', 'optimist'];

npm.load({
    loglevel: 'silent',
    'cache-min': 999999999999
}, function(err) {
    if (err) throw err;

    console.time('npm install');
    npm.commands.install(modules, function(err, data) {
        if (err) throw err;
        console.timeEnd('npm install');
    });
});

posting this here in case it helps anyone else

So ran into one more problem-- including npm as a dependency is pretty expensive as far as weight and install-time for your module. What would be great is to use a user's local npm which is already installed-- which could probably be achieved through some sort of npm trickery I couldn't figure out-- but for the short term, I put this together:

https://npmjs.org/package/enpeem

It's a very thin wrapper around using require('child-process').exec to access the globally installed npm on the system. It tries doing an npm -v first to make sure something version-esque gets printed to stdout, and if it doesn't it fails with a somewhat helpful message explaining that npm isn't available, and so the dependencies will need to be manually installed.

Of course, the jackpot would be if npm could be require()'d without having to npm install itself-- but in the meantime, this gets the job done.

Member
timoxley commented Jan 7, 2014

Would like this feature for npm search as well npm/npm-registry-client#35

An --offline and/or --cache flag should definitively be a thing, these are much more descriptive and intuitive than this hacky --cache-min 9999999 solution.

@svnlto svnlto referenced this issue in hoodiehq/hoodie-cli Jan 23, 2014
Closed

force install from cache #74

majgis commented Mar 14, 2014

In my case, setting cache-min had no effect. A locally installed karma was causing npm install --no-registry to fail. Installing karma globally fixed the problem.

I've tried to advocate the use of --cache-min 9999999 but due to this not being that trivial to commit to memory/use often, I still see value in a proper --offline flag being baked in. --no-registry is still broken afaik.

aramk commented Jun 19, 2014

It should reduce a lot of time if npm checked the cache before making so many network requests when installing libraries. Adding --offline would be nice.

It should reduce a lot of time if npm checked the cache before making so many network requests when installing libraries. Adding --offline would be nice.

@aramk it does, I believe. @isaacs or @domenic can correct me if I'm wrong here, but I think the reason it may seem kind of "grabby" about network requests is to resolve ^x.y.z-style dependencies. I'm not sure the cache-min setting currently applies for "is there a new version?" types of lookups. I'll have a peek around the source when I have a moment sometime and see if I can't confirm or invalidate that hypothesis.

@kkaempf kkaempf added a commit to kkaempf/npm2rpm that referenced this issue Jul 29, 2014
@kkaempf kkaempf Enforce use of local cache during %install 2efd0ae

Why isn't this simple issue still resolved?

Member
domenic commented Aug 22, 2014

Because you haven't written a pull request for it?

Wrong.

Work harder, comrade.

Contributor

@kuchumovn

  1. This is not a simple issue, as the npm cache is integral to npm's job as an installer, and it currently has pretty tightly coupled code. If you believe otherwise, you can prove it by submitting a fix in a PR.
  2. We are working on a fix, by factoring the caching code out into an independent npm-cache module with its own API. This is one of many projects the npm team has under way, so progress is slow but steady.
  3. Being rude to npm contributors will not make the work happen any faster.
@othiym23 othiym23 added this to the cache rewrite milestone Sep 16, 2014

It would be great to get an update to this issue. Problem with --cache-min 9999999 is that installing dependencies in a tree does not work: it expects packages to be installed in a flat hierarchy. In a perfect world I could add several packages in the cache and then install only one; the rest would be automatically used as dependencies to the top-level package.

@bseng bseng referenced this issue in kmees/MSBuild.NodeTools Oct 27, 2015
Open

Make use of Npm cache on default #29

Using --cache-min 999999 will also fail npm install whenever you install a package that depends on a newer version of a package you installed in the passed. Took me a while to figure out why that happened:

screen shot 2015-12-18 at 23 05 38

Member

@despairblue Yep it's painful. Tracking that issue here #8581

@cowboy cowboy referenced this issue in bocoup/deployment-workflow Dec 20, 2015
Merged

only npm install if you need to #67

Does someone understand what is the main purpose of the npm cache directory if running twice 'npm install package' generate two http requests?

Contributor

@nicgirault When packages are in the cache, the initial metadata request sends the cached etag for the package, and in the vast majority of cases, the registry will return a 304 and the package tarball won't need to be downloaded again.

@othiym23 thank you, your answer is clear.

This may now be relevant.
strongloop/loopback#1079

Contributor

@zachborboa That's strictly an issue with StrongLoop's packages, and is unrelated to this issue.

@othiym23 I still think it is related. If the optional dependency were truly cached, they would only ever receive a single (analytics) ping for the specified version.

Contributor

That's not how the cache works, @zachborboa – it's always going to fire off a request to see if it has the latest version of a resource. Having an "offline" or "use the cache only" mode would prevent those network checks, and, barring what changes would come from making the cache content-addressable / read-through by fetching tarballs from the cache by their shasums, not the default mode for the cache, now or in the planned future. Discussion about how StrongLoop uses optionalDependencies belongs over there, and is not a part of this discussion.

@jdalton jdalton referenced this issue in SBoudrias/Inquirer.js Feb 20, 2016
Closed

Use lodash modules #275

mriehema commented Mar 8, 2016

Adding --offline (=install from cache) would be nice.

Hi, I wrote this simple module https://github.com/harish2704/npm-offline-registry to address the same issue.

Hope it will help some who is checking this thread

@Zirak Zirak added a commit to Zirak/npm that referenced this issue Mar 26, 2016
@Zirak Zirak install: Add --from-cache to force using the cache
When passed, the registry client will favour taking modules from cache
instead of hitting the network.

Begins to address #2568 and its ilk.
b2a4aaa
Contributor

See #12061 for some of the nuances about how the caching should allow matching against semver ranges, which I believe it doesn't currently do, due to its dependence on the registry for range matching.

In Maven, a download is only attempted if the required dependency version is not already in the cache. This way if you already downloaded an artifact before, it will always come from the cache, not requiring an internet connection at all.

@kvanrobbroeck IMHO that should be the default expected behavior from npm. I personally don't think there is a need to fire a HTTP request since you can check the dependency locally. I think every package manager should have an offline first approach.

despairblue commented Apr 23, 2016 edited

This is not really possible because of semver ranges. There could always be
a newer patch release.

if there has been a newer publish in the semver range, that isn't in the cache, but the one in the cache is valid, then install the one in the cache.

That could lead to security releases never making it to the end users. That's also another thing: deprecating packages. The package in your cache could have been deprecated by the author because it was seriously flawed in some way. You wouldn't know if npm did not check.

Contributor

We use shrinkwrap for all production systems anyways, so pkgs are already
locked to specific versions - you opt into security updates from time to
time. But even with shrinkwrap installations are very slow.
On Mon, 25 Apr 2016 at 22:40, Danny Arnold notifications@github.com wrote:

That could lead to security releases never making it to the end users.
That's also another thing: deprecating packages. The package in your cache
could have been deprecated by the author because it was seriously flawed in
some way. You wouldn't know if npm did not check.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#2568 (comment)

@despairblue always installing the new package could just as easily introduce a security breakage.

despairblue commented Apr 26, 2016 edited

Depends on your semver range and how the project is maintained. Pinning
major and minor and installing the newest patch release should have a lower
chance of introducing a security flaw, though in theory it can, correct.
But this is another discussion.

The main problem is that maintainers can remove vulnerable packages or
deprecate unsupported ones. Npm will tell you that when you install it, but
only if it checks online. The package information is not immutable. That
makes caching hard.

Installing npm onsite can mitigate that, also the number of requests could
be reduced and even an offline switch can be introduced, but not checking
npm.com by default seems like a bad choice to me. Rather make it opt-in.

@despairblue no one is suggesting to make installs from cache the default, it's about making it possible to install from the cache.

This has worked, and then been broken at various times, it's working relatively well right now.

it's ugly, but npm install foo --cache-min 999999999 works.

despairblue commented Apr 26, 2016 edited

It was suggested just a couple of posts above. And your suggestion has a
minor flaw described on my comment a couple of months ago (when a dep
depends on a version of a package not in your cache). Answering from my
phone so linking is kind of hard.

Anyway, I think this is getting off topic. I didn't mean to suggest that
you wanted install from cache by default. :)

I was pointing out that Maven does indeed install from the cache by default, and has done so since forever. Maven also supports semver-like negotiation, so I can't imagine that would be a big issue.

I do agree with the point that it should be possible to install purely from cache because it would increase flexibility in cases where you (temporarily) don't have an internet connection (plane, train, transients, ...).

I also think the argument to not make this the default but an opt-in (so unlike Maven), is sensible for a modern package manager in the "age of the internet", because that may indeed be better for security updates and things. If this is not desired you can still play with the semver wildcards i guess.

Finally I think this option should be explicitly named something like --offline (as already suggested) rather than the ugly --cache-min trick from a usability point of view.

Member

Good news related to this: There's now an open PR that purports to allow the cache-min trick to be used reliably #12084

xealot commented Apr 27, 2016

While this thread has wandered slightly off topic, I think the cache-first approach has merit. I appreciate the desire for everyone to always get upgrades all the time without asking, but it can lead to new unexpected breakages.

Would it be unreasonable to quickly install from the cache and then perhaps display a list of outdated modules on the summary page? I think installing from cache should definitely be prioritized if there is an exact version specified in package.json which also exists in the cache.

There is a lot of npm install pain in my organization because we typically work on dozens of modules simultaneously that have similar/exact requirements in common. Installing the same version of gulp six times in a row without any caching feels broken.

How is the progress regarding this issue? Cache priority would be much appreciated. Even a full blown recursive one time install force flag as well.

@MylesBorins MylesBorins added a commit to MylesBorins/citgm that referenced this issue Jun 16, 2016
@MylesBorins MylesBorins npm: use --cache-min 999999 when installing
This forces npm to use the internal cache if possible

I believe that this should result in significantly faster install times

Ref: npm/npm#2568
32cc590
@MylesBorins MylesBorins added a commit to nodejs/citgm that referenced this issue Jun 22, 2016
@MylesBorins MylesBorins npm: use --cache-min 999999 when installing
This forces npm to use the internal cache if possible

I believe that this should result in significantly faster install times

Ref: npm/npm#2568
0d4ae1c
xandris commented Oct 21, 2016

I'm trying to have our build deploy to npm's cache and install from there, but it doesn't seem to work. The files end up in ~/.npm/foo/1.0.0, but npm install foo@1.0.0 still tries to contact the registry and fails. Is this use case possible with npm install --cache-min=Infinity <name>, or do we have to install from a tarball/directory?

This is still an issue. I have cache-min set to 7200, then I go to packageA and and do an npm cache clean packageA, followed by an npm cache add packageA-0.0.1.tgz. I can see that the right version is in the local cache after the cache add because the timestamp was updated. Then I go to packageB that has a dependency on packageA@0.0.1, but when I run npm install I can see looking at the cache that it still has the version I added to the cache, yet the version of packageA that packageB pulled down came directly from the registry, not only that, but it didn't even update the cache with what it pulled from the registry.

Contributor

Even with --cache-min Infinity npm checks etags on every module. The delta between a fully primed cache and an empty cache is pretty close to negligible (at least in the tests I've been running).

danshome commented Jan 31, 2017 edited

I'm so confused here. What is the point of even having a local cache if you ignore it? If I have my cache-min set to 7200, then I run the command "npm cache add packageA-0.0.2.tgz" to add version 0.0.2 of a module to my local cache, if I switch over to build another package (packageB) that has a dependency packageA and build it, then as long as they share the same npm cache I would expect that packageB would have pulled the npm package for packageA from my local cache, but it doesn't, it always grabs it from my npm registry and ignores what's in the cache.

MrGrande commented Feb 2, 2017

Hi, i'm struggling since days to create an "offline" usage of npm with the npm enterprise soution. But its not possible to install the packages from the cache. Even if they are cached by npm enterprise with their automatic whitelisting feature.

Background: I am working i a secured environment with limited internet access. Its not allowed to download any executable binary by the developers directly. Instead a developer has to ask for a package which must be checked for security issues (security department in the company) and after that it can be used/installed by the developers.

Does anybody know what could be the best solution in this case?

andreineculau commented Feb 2, 2017 edited

@MrGrande in a similar environment, what we do is three-fold

  1. use npm install --global-style xyz and archive the node_modules/xyz artifact in your company's artifact store
  2. grab artifacts from the store and unzip them.
    you can simplify 1 and 2 by requiring your devs to have their package.json use only static version specifications so that you know apriori to store and download e.g. store://xyz@1.2.3
  3. since this can create a rather large node_modules folder, one can later (in a packaging/deployment step) use npm dedupe to restructure the folder and remove duplicates. FWIW we are actually using npm v2 because the newer versions mess things up for us.

YES, it's a mess!
We're looking at switching to yarn, as soon as the above features are implemented yarnpkg/yarn#877 . Thanks in advance if you +1 the issue.

MrGrande commented Feb 2, 2017

Hello @andreineculau, thanks for the fast answer.

What do you mean with artifact store?
Please, can you describe point 1 and 2 a bit better?
Is it possible to use the cached packages completely offline?

Yapp, yarn would be nice but it takes a while until we can use it in production.

Thanks!

@MrGrande a bit more in detail, point 1 would be implemented as parse package.json; loop through the dependencies and/or devDependencies and for each package and package version, you would install it in a temp folder with --global-style, zip and store the file.
This point 1 would be done whenever the package is vetted as ok bye the compliance team, etc.

point 2 would be implemented as parse once again package.json; loop through the dependencies and/or devDependencies and for each package and package version, check if node_modules/xyz/package.json says that the package is already installed; if not you would fetch the zip from wherever you stored it, unzip it inside the node_modules
This point 2 would replace your devs' "npm install" step.

Point 1 and 2 basically shortcircuits npm install altogether, allowing you to use only cached packages.

"yarn would be nice but it takes a while until we can use it in production."

I have no idea what you just meant there because neither npm, nor yarn, nor any other package manager should be used in production, for anything, less alone installing software.

MrGrande commented Feb 2, 2017

@andreineculau.. Thanks...I need to think about your solution, its sounds really complicated.

You're right, i ment yarn is new and needs time to provide all required features to be used instead of npm.

MrGrande commented Feb 2, 2017

@andreineculau.. What do you think, is JFrog's Artifactory (https://www.jfrog.com/artifactory) a good solution for my problem? I havent tested it but they offer "Offline access to packages and metadata" in their feature list. I tried npm Enterprise but i am not able to fetch the packages from the cache.

My test case with npm Enterprise: I have a linux server running npme. The registry url is pointing to the npme server and i can see that packages are cached after a "npm install".
After that i removed all node_modules from my project, removed the internet acces for the npme server and tried another time "npm install" but it failed.
My thinking was that the developers can install the packages from the cache too, even if the server has no internet access at that moment.

@MrGrande I will reframe from more comments on the matter. Any good developer has more than enough info to get something working. On top of that, I don't want to participate in hijacking the thread even more.

danshome commented Feb 2, 2017 edited

@kvanrobbroeck @othiym23 @hunterloftis Why not just make the npm global cache work like every other cache--where locally cached assets are used until the asset has "expired". It's also important to note that E-Tag's can't always be depended on because in situations where requests are load-balanced across a cluster of webservers e-tags are often unset, so if npm is depending on e-tags exclusively, then that's probably a bad idea to begin with, E-tags can be used as a tool to improve caching performance, but you can't assume they will always be there, so you must fall back to the old Is-Modified-Since/Last-Modified approach.

Here's the way it should work in my humble opinion (yes I realize this doesn't cover all the bases, this is just a simple example which today does not work). Let's say I have --cache-min set to 5 minutes. Then I run the command "npm cache add packageA-0.0.2.tgz" to add version 0.0.2 of a module to my local cache, if I switch over to build another package (packageB) that has a dependency packageA and build it, then the first thing "npm install packageA@0.0.2" should do is simply check the timestamp on packageA in the global cache and if it's timestamp is within the last 5 minutes defined by --cache-min then there is no reason for npm to ever check the registry. However, if 5 minutes has passed, and npm has been requested to install the exact same version (ex. "npm install packageA@0.0.2"), then check the registry, sending If-Modified-Since/ If-Unmodified-Since AND If-Modified/If-None-Modified "IF" you have the E-tag, using the modified date/time of packageA in the global cache. If the server responds with a 304, then npm can proceed to use what's in the global cache, otherwise the server will respond with a 200 if the Last-Modified time on the server is later Is-Modified-Since/If-Unmodified-Since and npm can update the global cache with packageA@0.0.2 from the registry that has a newer modified time and can proceed to install the newer copy of packageA@0.0.2 that was in the registry. Note the reason I mention both Is-Modified-Since/If-Unmodified-Since is only because I haven't debugged npm communications yet to see if it's doing a POST or GET.

@zkat zkat added a commit that referenced this issue Apr 17, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
2fecc4a
@zkat zkat added a commit that referenced this issue Apr 18, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
6394384
@zkat zkat added a commit that referenced this issue Apr 18, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
576d441
@zkat zkat added a commit that referenced this issue Apr 18, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
e73f895
@zkat zkat added a commit that referenced this issue Apr 18, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
2d69994
@zkat zkat added a commit that referenced this issue Apr 19, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
e61a3fd
@zkat zkat added a commit that referenced this issue Apr 19, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
71396ca
@zkat zkat added a commit that referenced this issue Apr 20, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
2042018
@zkat zkat added a commit that referenced this issue Apr 20, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
9ce43d8
@zkat zkat added a commit that referenced this issue Apr 22, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
aa7d46e
@zkat zkat added a commit that referenced this issue Apr 22, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
412f1f5
@zkat zkat added a commit that referenced this issue Apr 22, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
86e22ee
@zkat zkat added a commit that referenced this issue Apr 22, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
78bf204
@zkat zkat added a commit that referenced this issue Apr 23, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.
d02e229
@zkat zkat added a commit that referenced this issue Apr 26, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.

fix(doctor): updated doctor command and its tests
8cf4c66
@zkat zkat added a commit that referenced this issue Apr 27, 2017
@zkat zkat feat(cache): rewrite package fetching and caching on top of pacote
Fixes: #2568
Fixes: #2649
Fixes: #3141
Fixes: #4042
Fixes: #4652
Fixes: #5357
Fixes: #5509
Fixes: #5622
Fixes: #5941

All fetching-related networking is now done through pacote, and
the old cache has been entirely replaced by a cacache-based one.

Features:

* npm now supports a variety of hash algorithms for tarball storage. On registries that support it, npm is able to use sha512sum for verification.

* An `integrity` field has been added to `npm-shrinkwrap.json`.

* Package integrity will be fully verified on both cache insert and extraction -- if npm installs something, it's going to be exactly what you downloaded, byte-for-byte, or it will fail.

* If `npm-shrinkwrap.json` is used, npm will bypass checking package manifests and go straight to the tarball, fetching it by content address if locally cached.

* Checksum integrity failures will now retry downloading on error, instead of failing on a single check.

* A new npm command, `npm cache verify`, can now be used to verify and garbage collect your local cache.

* npm now supports arbitrarily large tarball downloads: tarballs will no longer be loaded entirely into memory before extraction.

* packages whose names only differ in casing, and packages from different sources/registries/etc will now correctly be cached separately from each other.

* Some performance improvements.

* Improved fetch retry logic will try harder to download your packages.

BREAKING CHANGE: many shrinkwrap and cache-related things have changed.

* Previously-created caches will no longer be used. They will be left in place, but data will need to be re-cached. There is no facility for rebuilding a cache based on an existing one.

* `npm cache ls` has been removed for now

* `npm cache rm` now always removes the entire cache. There is no granular removal available for now.

* git dependencies can now use semver resolution using `#semver:^1.2.3`

* `--cache-min` and `--cache-max` have been deprecated. Use `--offline`, `--prefer-offline`, and `--prefer-online instead. `--cache-min=9999+` and `--cache-max=0` have been aliased to `--prefer-offline` and `--prefer-online`, respectively.

* npm will now obey HTTP caching headers sent from registries and other remote HTTP hosts, and will use standard HTTP caching rules for its local cache.

* `prepublishOnly` now runs *before* packing the tarball.

* npm no longer supports node@<4.

fix(doctor): updated doctor command and its tests
c63d8cd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment