Skip to content

Instantly share code, notes, and snippets.

@othiym23

othiym23/the-npm-cache.md

Created April 19, 2016 05:49
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save othiym23/b5e9a2509729b2aee974f4c3b2111912 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save othiym23/b5e9a2509729b2aee974f4c3b2111912 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. othiym23 created this gist Apr 19, 2016.
    132 changes: 132 additions & 0 deletions the-npm-cache.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,132 @@
    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](https://en.wikipedia.org/wiki/HTTP_ETag))
    - 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](https://git.kaarsemaker.net/git/commit/a8a5406ab32fccabf8ed08001d50b5373e18ff1a/) 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: _[email protected]_