Skip to content

Commit

Permalink
fix(doc): update DESIGN.md s/engines.pm/packageManager/ (#141)
Browse files Browse the repository at this point in the history
Fixes: #140
  • Loading branch information
x11x authored Jul 21, 2022
1 parent fdb187a commit d6039c5
Showing 1 changed file with 4 additions and 6 deletions.
10 changes: 4 additions & 6 deletions DESIGN.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,9 +26,9 @@ Discussion thread: https://github.com/nodejs/node/issues/15244

3. Regular users would keep using the `yarn` / `npm` / `pnpm` global binaries just like they are used to. The one difference is that the package manager implementations would be lazily downloaded, without having to be manually installed (because the global jumpers would be included in the Node distribution, cf previous point).

- Projects that don't list the `engines.pm` field would allow any package manager, and Corepack would install them based on predefined versions. Those versions will be frozen in time within Corepack itself to "known good values". For example, the default npm version could be 6.14.5, and the default Yarn one 1.22.4. Users that would want to upgrade to higher versions would just have to update the `engines.pm` field (cf next section).
- Projects that don't list the `packageManager` field would allow any package manager, and Corepack would install them based on predefined versions. Those versions will be frozen in time within Corepack itself to "known good values". For example, the default npm version could be 6.14.5, and the default Yarn one 1.22.4. Users that would want to upgrade to higher versions would just have to update the `packageManager` field (cf next section).

4. Project authors would most of the time only have to care about the binaries as well, but they would be able to upgrade package manager versions simply by changing the versions set in the `engines.pm` field.
4. Project authors would most of the time only have to care about the binaries as well, but they would be able to upgrade package manager versions simply by changing the versions set in the `packageManager` field.

- Corepack could reasonably provide some kind of basic CLI interface to select a version to upgrade to in a few keystrokes (similar to what `emsdk` does for the [emscripten toolchain](https://github.com/emscripten-core/emsdk#how-do-i-check-for-updates-to-the-emscripten-sdk), or what [nvm](https://github.com/nvm-sh/nvm) does for Node releases).

Expand All @@ -42,13 +42,11 @@ Discussion thread: https://github.com/nodejs/node/issues/15244

## How does it work?

When any of the embed binaries are called (whether it's `yarn`, `npm`, or `pnpm`), the tool will find the closest ancestor `package.json` for the current directory. It will then extract the `engines.pm` key, configured as such:
When any of the embed binaries are called (whether it's `yarn`, `npm`, or `pnpm`), the tool will find the closest ancestor `package.json` for the current directory. It will then extract the `packageManager` key, configured as such:

```json
{
"engines": {
"pm": "yarn@^2.0.0"
}
"packageManager": "[email protected]"
}
```

Expand Down

0 comments on commit d6039c5

Please sign in to comment.