Skip to content

Commit d6039c5

Browse files
authored
fix(doc): update DESIGN.md s/engines.pm/packageManager/ (#141)
Fixes: #140
1 parent fdb187a commit d6039c5

File tree

1 file changed

+4
-6
lines changed

1 file changed

+4
-6
lines changed

DESIGN.md

+4-6
Original file line numberDiff line numberDiff line change
@@ -26,9 +26,9 @@ Discussion thread: https://github.com/nodejs/node/issues/15244
2626

2727
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).
2828

29-
- 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).
29+
- 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).
3030

31-
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.
31+
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.
3232

3333
- 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).
3434

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

4343
## How does it work?
4444

45-
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:
45+
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:
4646

4747
```json
4848
{
49-
"engines": {
50-
"pm": "yarn@^2.0.0"
51-
}
49+
"packageManager": "yarn@2.0.0"
5250
}
5351
```
5452

0 commit comments

Comments
 (0)