Skip to content

Instantly share code, notes, and snippets.

@othiym23

othiym23/the-npm-cache.md

Created April 19, 2016 05:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save othiym23/b5e9a2509729b2aee974f4c3b2111912 to your computer and use it in GitHub Desktop.
Save othiym23/b5e9a2509729b2aee974f4c3b2111912 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
the-npm-cache.md

autoscale: true

[fit] the npm cache

[fit] the part of the animal nobody likes

what is it for?

  • caching*
  • search*
  • installer support

^ packages, Git, ETags ^ the less said about search, the better

what's in there?

  • package metadata (package.json*)
  • registry metadata (HTTP ETags)
  • package tarballs
  • installer lockfiles
  • Git remotes
  • search data*

^ not the same as what's in your package, or on the registry (_from, other headers) ^ registry metadata is the above plus the ETag

what can I put in there?

  • packages from a registry
  • hosted Git repositories
  • local directories
  • local tarballs
  • remote tarballs via HTTP[S] URLs

^ not just GitHub – gitlab:, gist:, and bitbucket: supported as well

how does it work?

  1. all installs go through the cache
  2. only hit network if registry metadata is stale
  3. only receive new packages if ETag is stale (no 302)
  4. always update Git clones

^ the caching logic figures out how to convert your registry requests into an installable package ^ as such, almost as complicated as the installer

how do I manipulate it?

  • npm install
  • npm cache
    1. npm cache clean
    2. npm cache ls
    3. npm cache add
  • npm search <thing>*

how do I fix it?

  1. npm cache clean <package>/<version>
  2. npm cache clean
  3. sudo rm -rf "$(npm config get cache)"
  4. rm "$(npm config get cache)/_locks/*"

Git commit-ishes & caching

npm caches per org/repo#name.

^ npm doesn't know what's a commit and what's a branch or tag ^ I looked up the correct spelling

the cache & shrinkwrap

Shrinkwrap bypasses the cache completely if resolved properties are set.

the cache & bundledDependencies

npm@3 is smart enough to fix problems with bundled versions; npm@2 mostly doesn't try.

optimizing complex applications for the cache

  • for shrinkwrap, if any dependency fails, whole install fails
  • very large packages are difficult to publish & install

using npm on a plane / the moon / at NodeConf

  • not designed for offline use
  • --cache-min=999999 will fake it
  • …but only if the cache is warmed for the packages you want

^ blows up if you try to install a package / version not found in cache

the semi-mythical cache rewrite

  • content-addressable cache
  • cacheable shrinkwrap
  • true offline mode
  • decouple from the installer & npm-registry-client

^ a true programmatic interface to the cache would be very handy ^ I've been trying to get to this for years ;_;

[fit] npm (still) <3 u

Twitter: @othiym23 GitHub: @othiym23 email: forrest@npmjs.com

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment