Add support for corepack

[elpoelma]

Overview

This PR includes support for corepack. Corepack is a tool to easily manage package managers like pnpm and yarn. It also allows you to manage different versions of these package managers.

By enabling corepack support, it should be straightforward for a user to utilize both pnpm and yarn. The package manager/version that is used depends on the packageManager field of the package.json file (https://nodejs.org/api/packages.html#packagemanager).

How to test/reproduce

• Run the release script to build a local version of docker-ember
• Run the edi command and ensure you have access to both pnpm and yarn
• The version of the package manager should depend on your packageManager setting. Otherwise, the latest stable version should be used.

Challenges/uncertainties

Unsure if we should set COREPACK_ENABLE_DOWNLOAD_PROMPT to 0. This environment variable controls whether a prompt is shown if the packagemanager version is not yet installed.

[abeforgit]

Most modern ember projects rely on the start script instead of running ember s directly (e.g. to run typechecking simultaneously as a separate process, rather than hooking into ember-cli). So too our current pnpm projects like the editor and the plugins.
This means that the edi command needs to gain the ability to expose its ports to the host.

Given that, I've confirmed the PR works to successfully install and run our projects

regarding COREPACK_ENABLE_DOWNLOAD_PROMPT: definitely turn it off, it becomes annoying very quickly

[madnificent]

Thank you for the PR and the solid description with links to upstream documentation.

Reading into corepack based on the links provided it seems this will install any version specified at runtime, defaulting to latest. One of the benefits of Docker Ember is to have the static set of dependencies so we have the same stable environment to run against each time. Installing the core dependency at runtime conflicts with that. Our aim is to have a streamlined environment which is shared rather than a situation where each project chooses a solution with slightly different upsides and downsides. Perhaps corepack can be used in such a setting.

The PR itself removes Yarn because it could now be manually installed through corepack (it is unnecessarily breaking because it removes yarn but doesn't add it through corepack AFAICT).

At this point corepack supports yarn and pnpm. It being experimental and lacking support for npm itself, I guess those will be the only ones supported in the future. Do you see path forward in which the versions are locked in? What would that look like? Is corepack the optimal approach when we're aiming for a shared environment used across projects? Installing a specific version up front through corepack does look clean to me with the added risk that projects rolls their own instead of using a shared standard. Would appreciate your input.

[elpoelma]

Corepack will indeed (by default) install and use the latest version of the specified package manager. This can however be controlled through the COREPACK_DEFAULT_TO_LATEST and corepack pack workflows (https://github.com/nodejs/corepack?tab=readme-ov-file#offline-workflow , https://github.com/nodejs/corepack?tab=readme-ov-file#environment-variables)

Additonally, a project can indeed pin/specify which package manager + version to use. This can ensure consistency when developing the app/addon. To adjust this logic, you can specify the COREPACK_ENABLE_PROJECT_SPEC environment variable.

While this PR indeed removes yarn as a seperately installed package, corepack does provide it, so this PR shouldn't be breaking. When executing the yarn command, corepack should install/enable it automatically.

So to provide the option to lock in versions of both pnpm and yarn I would:

• set COREPACK_DEFAULT_TO_LATEST to 0. This ensures corepack doesn't download the latest versions by default
• set COREPACK_ENABLE_PROJECT_SPEC to 0. This ensures corepack ignores the packageManager field of the current project, and uses the globally installed yarn/pnpm instead
• corepack pack allows you to bundle specific package managers (and specific versions) in your image, this will also ensure offline usage.

I do however also like that projects themselves may specific which package manager they use (especially if that project is also used outside a docker-ember context)

Corepack indeed does not (weirdly enough) support npm itself. This means the npm version used will be the one bundled with the current node version (or a manually installed one).