Add a package_manager option with pnpm support - #676
Merged
Conversation
The gem only knew how to install an Ember application's dependencies with npm or, behind the `yarn` option, Yarn. `ember-cli` has generated pnpm-based applications since `ember new --pnpm` landed in 5.1, and those applications carry a `pnpm-lock.yaml` that `npm install` ignores, so a Rails project could not deploy one through `assets:precompile` without installing its dependencies by hand first. Introduce a `package_manager` option (`:npm`, `:yarn`, or `:pnpm`) rather than a `pnpm: true` flag next to `yarn: true`: two booleans can both be set at once, and every further package manager would repeat the conflict. `yarn: true` stays as shorthand for `package_manager: :yarn`, and `pnpm_path` implies pnpm the way `yarn_path` implies yarn, so no existing configuration changes meaning. The package manager is read through the new `EmberCli::App#package_manager` and `EmberCli::App#pnpm?`. There is no `pnpm prune` beside `pnpm install`, unlike the npm branch: `pnpm install` already drops the packages `package.json` no longer lists. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Heroku's NodeJS buildpack picks its package manager from the lockfile at the project root, so `rails generate ember:heroku` now writes an empty `pnpm-lock.yaml` for a pnpm project, the way it writes `yarn.lock` for a Yarn one, and copies the `packageManager` field the Ember applications declare (read through the new `EmberCli::App#package_manager_spec`) into the generated `package.json`, since the buildpack otherwise installs the latest pnpm release with a warning. The generator spec's `configure_application` now registers only the application under test instead of adding it to the shared configuration, so that the dummy project's own applications take no part in the generator's `EmberCli.any?` checks. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
tricknotes
force-pushed
the
support-pnpm
branch
from
September 9, 2026 15:34
75647c6 to
4a59dff
Compare
tricknotes
changed the title
`yarn: true` still selects yarn, but now warns through the new `EmberCli.deprecator` (an `ActiveSupport::Deprecation` with a `1.0` horizon, registered with the application's deprecators on Rails 7.1 and later so that `config.active_support.deprecation` applies to it) and points at `package_manager: :yarn`. `yarn_path` alone keeps implying yarn without a warning, as `pnpm_path` implies pnpm. `PathSet#package_manager` memoizes its answer so that the warning is printed once per application rather than on every query. The specs that are not about the shorthand configure yarn through `package_manager`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
`PACKAGE_MANAGER` selects the package manager `bin/setup_ember` installs the dummy application's dependencies with: `npm` (the default), `yarn`, or `pnpm`, with any other value failing early. `yarn install` and `pnpm install` serve the Vite-based blueprint, and `yarn add --dev` and `pnpm add --save-dev` the classic one, where they install the rest of the dependencies alongside `ember-cli-rails-addon` the way `npm install` does. The dummy application's initializer registers the same package manager, so that `ember-cli-rails` runs against the `node_modules` that package manager laid out. CI adds one Yarn and one pnpm job per blueprint (Vite-based `7.0.0` and classic `5.12.0`), installing Yarn 1 and pnpm 10 explicitly, so that the `yarn` and `pnpm` branches of `Shell#install` run against a real `node_modules` rather than only against the stand-in executables in its spec. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
tricknotes
force-pushed
the
support-pnpm
branch
2 times, most recently
from
September 9, 2026 15:44
3879c7e to
4283396
Compare
tricknotes
marked this pull request as ready for review
September 9, 2026 16:24
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds pnpm as a package manager for installing an Ember application's NodeJS dependencies, behind a new
package_manageroption, and deprecates theyarnoption in its favour.package_manageroption (740648e)::npm(the default),:yarn, or:pnpm.pnpm_pathimplies pnpm the wayyarn_pathimplies yarn, so existing configurations keep their meaning.EmberCli::Shell#installrunspnpm installfor a pnpm application (there is nopnpm prunebeside it:pnpm installalready removes the packagespackage.jsonno longer lists),EmberCli::PathSet#pnpmresolves the executable frompnpm_pathor$PATHand raisesDependencyErrorpointing at https://pnpm.io/installation when it is missing, andEmberCli::App#package_manager/#pnpm?expose the choice.df35d2c):rails generate ember:herokuwrites an empty root-levelpnpm-lock.yamlfor a pnpm project (Heroku's NodeJS buildpack selects the package manager by lockfile) and copies thepackageManagerthe Ember applications declare (the newEmberCli::App#package_manager_spec) into the generatedpackage.json, so the buildpack pins that version instead of falling back topnpm@latest. The generator spec now registers only the application under test instead of mutating the shared configuration.yarn: truedeprecated (fd614d9): it still selects yarn, with a deprecation warning through the newEmberCli.deprecator(anActiveSupport::Deprecationwith a1.0horizon, registered with the application's deprecators on Rails 7.1 and later), printed once per application. The README documentspackage_manageronly; theyarnoption is kept for compatibility and is no longer listed.4283396):PACKAGE_MANAGER=yarn bin/setupandPACKAGE_MANAGER=pnpm bin/setupinstall the dummy application with Yarn 1 or pnpm and register it with the matchingpackage_manager(npm stays the default, any other value fails early), and CI runs one such job per package manager and blueprint (Vite-based7.0.0and classic5.12.0), so that anode_moduleslaid out by each package manager is exercised through the whole suite rather than only by the stand-in executables inShell#install's spec.Test plan
bin/setup && bin/rakewithember-new-outputv7.0.0 (Vite), npm: 192 examples, of which the 186 that do not drive a browser pass; the 6 browser-driven examples could not run in that environment (no chromedriver)PACKAGE_MANAGER=yarn bin/setup_ember && PACKAGE_MANAGER=yarn bin/rakewith v7.0.0: the same 186 pass, same 6 could not runbin/rspec spec/lib spec/generatorson its own (apart from the browser-drivenEmberCli::App#testexample)4283396, including the twoyarnand twopnpmjobsFollow-ups (not in this PR)
packageManager/ the lockfile when no option is given