Enable Ember CLI users to opt into using
pnpm for package management.
pnpm is a popular alternative to both
yarn that prioritizes correctness, especially for
peerDependencies and monorepos.
pnpm has very active maintainance, support, and financial funding.
Their website states that
pnpmis up to 2x faster than the alternatives
- Efficient: Files inside
node_modulesare cloned or hard linked from a single content-addressable storage
- Supports monorepos:
pnpmhas built-in support for multiple packages in a repository
pnpmcreates a non-flat
node_modulesby default, so code has no access to arbitrary packages.
For folks with lots of projects on their computers,
pnpm is extremely space-efficient.
yarn would duplicate
pnpm will only download a package (at a specific version) once across your whole machine.
yarn repeatedly have demonstrated that their strategies with
peerDependencies are not correct, and it is vitally important we use and support a tool that can guide folks towards correctly creating addons. For example,
@embroider/macros relies on node's resolution algorithm, so having
peerDependencies resolved correctly is important for
dependencySatisfies to work as expected in monorepos.
Ember CLI currently only supports
npm (default) and
yarn for project initialization as well as various commands. At present, projects work with
pnpm, but the tooling is unaware.
pnpm is designed as opt-in to prevent disruptions to developer's current workflow, much the same as
There are a few integration points that we must support for
pnpm (and any package manager):
- generated C.I. configs
There are two mechanisms through which to opt-in.
The first one is the presence of a
pnpm-lock.yaml file in the project root.
pnpm-lock.yaml file is generated by
pnpm when you run
pnpm install (or the shorter
so we assume that its presence means the developer intends to use
pnpm to manage their dependencies.
Alternatively you, you can force Ember CLI to use
pnpm with the
ember install ember-resourceswith
pnpm-lock.yamlpresent will use
ember install ember-resourceswithout
pnpm-lock.yamlpresent will use npm
ember install ember-resources --pnpmwill use
Since this triad of commands is generally ran before a project is set up, there is no
pnpm-lock.yaml file presence to check.
This means we are left with the
--pnpm flag, which will also be added to these commands:
ember new my-appwill use npm
ember new my-app --pnpmwill use
The above also applies to
ember addon and
ember init, noting that
ember init doesn't receive any arguments.
--skip-npm flag actually means "skip installation of dependencies" when using
ember addon and
including skipping installation with both
This will need to be extended to also skip installation of dependencies when
pnpm is used.
ember new my-app --pnpm --skip-npm
At the time of writing this RFC,
ember-try already supports
pnpm, but it is undocumented in the README.
Documentation will need to be added to the README,
as well as the relevant
ember-cli blueprints will need to correctly configure
usePnpm: true in the
ember-try.js config file when the
pnpm flag is present.
generated C.I. configs
At the time of writing this RFC,
ember-cli supports two C.I. environments: Travis and GitHub Actions.
.github/workflows/ci.yml config files for relevant blueprints will need to support the
pnpm option such that C.I. passes on new projects using
Addons should be stricter than defaults, so that they are good stewards of the ecosystem and don't leak accidental uncertainty to their consumers.
In addon projects, the
.npmrc will need the following defaults:
# all peer dependencies must be declared or forwarded to the consumer auto-install-peers=false # we want true isolation in addons -- if a dependency is not declared, we want an error reslove-peers-from-workspace-root=false
These pages presently mention
yarn and will need to be updated to include
How we teach this
The Ember Guides should be updated to reflect the new flags, where applicable,
as well as the new behavior of
ember install in the presence of a
pnpm-lock.yaml -- though most of the guides use
ember as the CLI tool for managing packages.
We may want to consider updating the tutorial (and its automation) to use
npm is very slow.
In addition, the built-in instructions for
ember help should be updated to reflect the new flags.
pnpmis very strict about peers and what dependencies are allowed in a project and will error if a project's package.json is incorrect for a given scenario.
pnpmis very clear about these errors and what to do for action items, but it means that we'll need to make sure that
pnpmis tested in
ember-cliwhen generating new projects so that we can be certain that folks' "first time experience" is smooth
- There may be other package managers in the future, but we cannot see the future. There have been talks about making ember-cli somehow generically handle package-managers, but it is unknown how that would work, and is unneeded for now.
- Figure out a way to generically handle any package manager
- Continue with the partial pnpm support we have today
- Are there any other references in the guides to
yarn? The only place I could find that mentioned
yarnis here: https://guides.emberjs.com/release/addons-and-dependencies/
- Is there a
--package-managerflag / option in
ember-cli? for blueprint authors, that may be useful.
--skip-npmbe aliased to