Search code examples
javascriptnode.jsgityarnpkg

Am I meant to commit yarn's `.pnp.js` file?

Yarn includes an optional "Plug'n'Play" feature which moves node_modules out of the project directory. In doing so it creates a .pnp.js file with references to various dependency paths on the hard drive.

The file is auto-generated, is several thousand lines long, and appears to reference paths specific to the machine that ran yarn install.

Is .pnp.js meant to be commited with the rest of the code? I can't seem to find any information about this despite the file appearing to be useless to commit. What is conisdered best practice and why?

Solution

  • I found this comment by Arcanis (the lead maintainer of Yarn) on an issue asking about what to include in a .gitignore. It may answer your question:

    • .yarn/plugins and .yarn/releases contain the Yarn releases used in the current repository (as defined by yarn set version). You will want to keep them versioned (this prevents potential issues if, say, two engineers use different Yarn versions with different features).

    • .yarn/unplugged should likely always be ignored, since it may contain native builds

    • .yarn/build-state.yml should likely be ignored as well, as it contains the build infos

      • If for some reason you version unplugged, it may make sense to keep build-state as well

    • .yarn/cache may be ignored, but you'll need to run yarn install to regenerate it

      • Versioning it unlocks what we call Zero-Installs - it's optional, though

    • .pnp.js (and potentially .pnp.data.json) are in the same boat as the cache. Add it to your repository if you keep your cache in your repository, and ignore it otherwise.

    • yarn.lock should always be stored within your repository (even if you develop a library)

    So to summarize:

    If you're using Zero-Installs:

    .yarn/unplugged
.yarn/build-state.yml

    If you're not using Zero-Installs:

    .yarn/*
!.yarn/releases
!.yarn/plugins
.pnp.*