The docs and comments indicate that corepack prepare should look at the package manager configured in package.json and download it, but it currently doesn't.

Repro

1. docker run --rm -it --entrypoint sh node:16.11.1-alpine3.14
2. echo '{"packageManager": "[email protected]"}' > package.json
3. ls ~/.node doesn't exist (expected)
4. corepack prepare
5. ls ~/.node doesn't exist (unexpected)
6. corepack yarn --version (shows 3.0.2)
7. ls ~/.node does exist (expected)

Now Node.js v16.9.0 includes corepack v0.9.0, please tag that version in the repository.

The current implementation uses engines.pm in order to define the package manager, but it's perhaps not the best location to store this information. The engines field intends to specify which versions of the package manager are capable of properly installing the package, not the project (the distinction matters: the project is whatever you clone, whereas the package is whatever people consume when running yarn add my-package).

In particular, engines are typically checked even on transitive dependencies whereas we would want the pmm definition to only be considered for the top-level manifest, and ignored for all others. It also avoids potential issues with older package managers that would print a warning with projects that would list an "unknown engine field".

Of note: package managers have their own fields in the engines field (respectively engines.npm, engines.yarn, engines.pnpm). Those would be completely ignore by pmm, which would only care about the top-level field. So, for instance, if you wish to indicate that your package needs to be installed by Yarn 1.20+ or npm 6+ and that its project needs to be developed using Yarn 1.22.4, you'd write:

{
  "packageManager": "[email protected]",
  "engines": {
    "yarn": "^1.20",
    "npm": "^6"
  }
}

Note however that I personally wouldn't recommend using engines.yarn (or any of the others) - a package should be compatible with every reasonable package manager.

C:\Users\jasne>corepack

C:\Users\jasne>corepack --help

C:\Users\jasne>corepack --?

C:\Users\jasne>corepack -h

C:\Users\jasne>corepack /h

;-) ....

How I encountered this error:

1. Updated to nodejs v16.9.0
2. $ sudo npm i -g npm
3. $ sudo npm uninstall -g yarn
4. $ corepack enable
5. Sanity check:

   $ which yarn
   /usr/local/bin/yarn
   
   $ cat /usr/local/bin/yarn
   #!/usr/bin/env node
   require('./corepack').runMain(['yarn', ...process.argv.slice(2)]);

6. I have an existing project with "packageManager": "[email protected]"
7. $ yarn --version outputs 2.4.2
8. I set packageManager to [email protected]
9. $ yarn --version outputs 2.4.2

Actually, any valid yarn version within ^2 I set it to still yields 2.4.2. Any 1.x version of yarn seems to be honored.

It appears that the bolded copyright line is the culprit.

Related #28

I saw you are using yarn in this repo, but not with corepack...

Corepack currently depends on the security of HTTPS. Projects that want stronger guarantees should optionally be allowed to configure an integrity hash for the downloaded package manager. Obviously this would only be possible when configuring an exact version rather than a range.

Integrity hashes for the default known-good versions should be included in Corepack, so that users get the strongest security guarantees by default.

(Related to #10, but without requiring modifications to the registry or the package managers.)

Related:

Hi,
I just installed node v16.9.0 (using nvm-windows) which supposed to include corepack right off the bat. But when I open terminal and typed corepack enable, I'm getting usual error corepack : The term 'corepack' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

I searched the whole drive for corepack and didn't find anything. So where is it? Do I still need to install it using npm?

One of the main reason we adopted corepack was to avoid work in nodejs/node to support multiple package managers. There is a measurable amount of traffic on our H1 due to vulnerabilities in the npm dependencies, and we are struggling to keep npm up to date. Unfortunately corepack increases this load and it makes it even less apparent and hard to track as the vulnerabilities would not be apparent to the users.

I propose that the config file include only the major version of each package manager. This will ensure that for a specific version of Node.js there won't be any breaking change (I consider the drop of a Node.js version a breaking change).
Then we will update the major version of each package manager whenever we ship a new major release of Node.js.

I would also recommend that the config file is not bundled in but loaded at runtime. This will simplify maintenance on the Node.js side so we could just update the config file without updating corepack (and viceversa). This also enables mulitple Node.js lines to have the same version of corepack but different defaults.

The prepare command will choose "Known Good Releases" when it is not specified with a version range. Generally [email protected], [email protected] and [email protected]. I'm wondering if it can just choose the last version of them. Because Node.js 16 is installed with npm@8, it is quite surprising that corepack enable gives me npm@7.

Currently corepack prepare requires a full version to work, i.e. x.y.z. When I want to upgrade npm to 8, I have to ask npm once to get the correct version (npm view npm or npm dist-tag ls npm, and copy the latest field).

So I hope corepack would have corepack prepare --latest to just install the latest version, or maybe corepack upgrade --interactive.

Corepack version: 0.9.0

Expected behavior: when using corepack enable expect to be able to tell it which version should be enabled, much like corepack use.

Actual behavior: corepack enable does not automatically download the latest version of the package manager in question by default. Which pnpm, it downloads 6.11.0 instead of 6.14.3 (latest as of the date of this post, 8/28/2021). It does not support the version string like corepack use does, e.g. corepack enable pnpm@latest is not supported.

This is not applicable to yarn, since yarn detects the version based on the .yarn directory and what version has been registered there.

EDIT: I know that you can do the following steps (which may be somewhat redudant here) to achieve this, I think it would be more straightforward (this was not obvious to me at least) if this was done by corepack enable in this scenario.

I was able to get it to use the latest version by doing the following:

• run corepack prepare [email protected] -o ./
• Then running corepack hydrate ./corepack.tgz --activate
• Finally, running corepack enable pnpm

The steps above resulted in the latest pnpm being available.

If this is in fact the desired flow for using arbitrary versions, I'm happy to help document this flow

Code currently hardcodes references to https://registry.npmjs.org, which makes corepack (and yarn) not usable inside a walled corporate network, even though that network might offer a local private repository for npm.

Also, even the DNS resolution of registry.npmjs.org might not be available in the walled scenario, in which case running (for example - and whichever parameter is used) yarn will return a not very informational:

Internal Error: Error when performing the request

This happens at least in the latest 0.10.0 release, with node.js v12.16.1 LTS.

We currently use rename, so the temporary directory can't be moved if on a different drive than where we're installing the versions. We should change the temporary directory to instead be next to the final location, or at least within the ~/.node folder (this way we're sure they're on the same drive as the destination).

I'm working to setup automatic updates & releases on the repository (first step was #88), but I don't have the permissions to manage the repository (in particular I need to add a secret for the npm publish step, and give the permissions for a bot user to bypass the branch protection on scheduled jobs, cf failed logs).

What's the process to do this?

cc @jasnell

This thread aims to discuss the "global packages" scenario. For example, the pmm version of pnpx --version is currently forbidden if run within a Yarn project, even though it's supposed to run within a standalone context that might not be related.

With pmm currently installed, the following currently happens when running npm install -g yarn:

npm ERR! code EEXIST
npm ERR! syscall symlink
npm ERR! path ../lib/node_modules/yarn/bin/yarn.js
npm ERR! dest /tmp/tmp.SfN0q4jxL7/node-v15.0.0-nightlyYYYY-MM-DDXXXX-linux-x64/bin/yarn
npm ERR! errno -17
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/yarn/bin/yarn.js' -> '/tmp/tmp.SfN0q4jxL7/node-v15.0.0-nightlyYYYY-MM-DDXXXX-linux-x64/bin/yarn'
npm ERR! File exists: /tmp/tmp.SfN0q4jxL7/node-v15.0.0-nightlyYYYY-MM-DDXXXX-linux-x64/bin/yarn
npm ERR! Remove the existing file and try again, or run npm
npm ERR! with --force to overwrite files recklessly.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/arcanis/.npm/_logs/2020-09-03T14_30_46_868Z-debug.log

There are a few options on the ideal behavior:

• Ask npm to assume --force when overriding the yarn binary (or any other binary covered by pmm). Pros, it preserves the current behavior, anyone who runs npm install -g yarn can keep doing it without changing their workflows. Cons, it means that they would effectively be replacing the pmm binary, so they wouldn't benefit from the "ensures the right version" anymore.

• Ask npm to exit with a zero exit code when it detects that the yarn binary points to pmm, and print a message explaining the situation with a link to the pmm project. Perhaps we could also make it change the default Yarn version that pmm would use for new projects. Pros, people can keep using their workflow, they don't accidentally overwrite their binaries and lose features. Cons, it's a bit magical, might be confusing to some users.

• Decide that this is the expected behavior, and that people upgrading to Node 15.x are expected to be aware that running npm install -g yarn isn't needed anymore. Potentially ask npm to improve the error message to explain the situation. Pros, fail early, this would make this improvement noticeable. Cons, it's maybe too noticeable, and CI providers would need to adapt to this change.

For reference, the ideal message I mention would be akin to:

npm ERR! Starting from Node 15.x, Yarn is partially distributed along with Node. To check that
npm ERR! is the case, run `yarn --version` in your project directory. More information on:
npm ERR!     https://nodejs.org/pmm/notice

With the url pointing to longer explanations.

"Details" section of corepack enable --help and corepack disable --help mentions --bin-folder flag:

By default it will locate the install directory by running the equivalent of
`which corepack`, but this can be tweaked by explicitly passing the install
directory via the `--bin-folder` flag.

But such a flag does not exist. I presume it was supposed to mention --install-directory?

Node -v give me that I have Nodejs v16.14.2.
As stated in the docs,

Corepack is included by default with all Node.js installs

So that mean my environment should already have Corepack. But run corepack enable give me error it's not recognized as a command

I like trying out new. IMHO That is the true test if it works for you.

One of the program I used was yarn so I had to enable it.

I would like to now use pnpm in my own project but if I run

pnpm install --silent

but it gives me

"Usage Error: This project is configured to use yarn"

It is a brand new project with nothing. I just made it with nestjs framework

nest new.

Edit:
For those who would like more explanation :)

Put this under '"name"' : in your package.json

"packageManager": "[email protected]"

We were discussing with @iansu the case where package managers are detected depending on whether they are or not in the global path (@ljharb mentioned that as well in another thread). Tracking some thoughts:

• Existing CRA & similar tutorials mention npm, so newcomers might be surprised if it gets installed via Yarn.

• At the same time, it would be similarly confusing if tools like CRA were to always default to npm, given their current behavior.

• If we do this Corepack thing, it's at least in part so that all package managers are on the same foot.

• The problem only affects scaffolders, since existing projects will necessarily already have their install creations.

One potential solution would be to offer a BrowserChoice-like system under the form of a Corepack command (let's say corepack elect for now) that, when called:

• If the command was never run before, it would print all supported package managers with an interactive interface listing their name and a link towards their respective websites. Upon selecting one of the options, Corepack would save the result inside its data folder, then would print the name of the selected package manager.

• If the command ran before, it would simply read the data previously stored inside the data folder, and print again without prompting the user.

From the integrator perspective, the way it would work:

• Instead of checking for Yarn's existence with things like yarn --version, the program would run corepack elect and capture the output. It would then branch depending on the result as before.

• They could still implement their flags like --use-npm or --use-yarn, so that users can override their choice on a per-command basis.

One nice effect is that this would make it much clearer for the users which package manager they would be using. Right now, it's difficult to know whether Yarn or npm will end up being used unless 1/ you know that CRA has this behavior, and 2/ you remember whether you installed Yarn or not (you may have installed it only for another project a long time ago).

On the minus side it means that tools like CRA would have to add support for this feature, so it would require their input to know how they would feel about this workflow.

I tried to do, as instance corepack prepare [email protected], but got Internal Error: Error when performing the request.
I think this is because of the proxy. Where I can configure it?
I have proxy setting in .npmrc, also I have HTTP_PROXY and HTTPS_PROXY environment variables

pnpm dist-tag will delegate the command to npm dist-tag and cause an error.

pnpm dist-tag react
Usage Error: This project is configured to use pnpm

$ npm ...

I suggest making some commands that can be run in any project like dist-tag because they do not do anything related to the project.

Getting a 403 error

$ nodenv global 17.1.0
$ npm ls -g --depth 0
/home/LOM0227/stow/nodenv/.nodenv/versions/17.1.0/lib
├── [email protected]
└── [email protected]

$ corepack enable
$ pnpm
Internal Error: Server answered with HTTP 403
    at ClientRequest.<anonymous> (/home/LOM0227/stow/nodenv/.nodenv/versions/17.1.0/lib/node_modules/corepack/dist/corepack.js:3933:31)
    at Object.onceWrapper (node:events:510:26)
    at ClientRequest.emit (node:events:390:28)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:623:27)
    at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
    at TLSSocket.socketOnData (node:_http_client:487:22)
    at TLSSocket.emit (node:events:390:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at TLSSocket.Readable.push (node:internal/streams/readable:234:10)

I suspect these hardcoded registries have something to do with that.

This doesn't work for environments that block the public registry and require a private registry like artifactory, eg,

$ npm config list
; "user" config from /home/LOM0227/.npmrc

//[redacted].jfrog.io/artifactory/api/npm/emf-npm-virtual/:_password = (protected) 
//[redacted].jfrog.io/artifactory/api/npm/emf-npm-virtual/:username = "lmarsano@[redacted].com" 
always-auth = true 
email = "LMarsano@[redacted].com" 
registry = "https://[redacted].jfrog.io/artifactory/api/npm/emf-npm-virtual/" 

Maybe lookup registry from config files?

Currently, corepack sits behind node_install_npm in node/tools/install.py

  if 'true' == variables.get('node_install_npm'):
    npm_files(action)
    corepack_files(action)

'node_install_npmis in turn set bynode/configure.py`

parser.add_argument('--without-npm',
    action='store_true',
    dest='without_npm',
    default=None,
    help='do not install the bundled npm (package manager)')
...
  o['variables']['node_install_npm'] = b(not options.without_npm)

This has the side-effect that when node is built w/o npm (configure.py --without-npm), then corepack is deselected as well. Ideally, corepack should sit behind its own configure flag (configure.py --without-corepack) instead.

npm v7 and v8 will upgrade the lockfile. that's inconvenient when working on projects you cannot control the upgrade of lockfile.

Some users will not want to download things dynamically. This should be addressed in the available tools.

Proposed workflow:

A command (let's say pmm hydrate) would install a tarball within the package manager cache:

pmm hydrate yarn-1.22.4.tgz
# Yarn 1.22.4 is in the cache, no dynamic install
yarn --version

How these archives will be retrieved doesn't matter: users have the responsibility for that. Some popular options will be:

• Store them directly within the repositories
• Download them from a private registry
• Cache them when building the docker images

To make the tarball creation easier, pmm would include a pmm pack [email protected] command that would generate the tgz file for the given package manager (in a format suitable for pmm hydrate).

Hello I am obviously brand new to this and I can follow along and I have all the information of what to put in As far as the codes repositories and all that but my problem is I don’t know where to put all that where do we start what do we have to open to input the codes into thank you

I'd like to write a package.json like:

{
  "packageJson": "pnpm@6"
}

Or maybe pnpm@^6.32.2, etc.

As it stands, adding a package manager to package.json requires a full specified version. This adds more maintenance overhead.

I think this is related to #93.

I'm trying to clone and install dependencies in a project which appears to use corepack, and I'm having a difficult time. I've tried to follow the directions, but am getting an error. Here's what I've done.

▶ node --version
v16.13.0

▶ corepack enable

▶ corepack prepare [email protected] --activate
Preparing [email protected] for immediate activation...

▶ corepack yarn install
Syntax Error: Unexpected identifier
(function (exports, require, module, __filename, __dirname) { version https://git-lfs.github.com/spec/v1
                                                                      ^^^^^

SyntaxError: Unexpected identifier
    at new Script (node:vm:100:7)
    at NativeCompileCache._moduleCompile (/Users/ianvs/.nvm/versions/node/v16.13.0/lib/node_modules/corepack/dist/vcc.js:251:18)
    at Module._compile (/Users/ianvs/.nvm/versions/node/v16.13.0/lib/node_modules/corepack/dist/vcc.js:195:36)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (/Users/ianvs/.nvm/versions/node/v16.13.0/lib/node_modules/corepack/dist/vcc.js:170:20)
    at $K (/Users/ianvs/.node/corepack/yarn/3.0.2/yarn.js:242:4931)
    at ql (/Users/ianvs/.node/corepack/yarn/3.0.2/yarn.js:242:5785)

I guess this is an error coming from corepack? I'm not really sure what's going on, to be honest. Let me know if there is anything else I can do to help debug. Thanks!

Hi 👋 I happened on this just meandering around the Node GH. I think this would be an excellent thing to provide with Node, but I’m concerned about some of what’s proposed.

Background

Based on my reading of README/issues clarifying progress, the current behavior is:

1. Install corepack
2. Use Yarn/PNPM commands as if the package manager is already installed in $PATH
3. If it’s not, corepath silently installs and executes it with the command entered

My understanding is that this will be be bundled with Node, eliminating step 1. While convenient, that makes the following steps troubling.

Risks

Users are executing code they didn’t take any affirmative steps to install. This is a clear security issue, but it’s (subtly) more too.

In terms of security risk, it’s similar to npx prior to NPM 7:

• It obfuscates what action the user is actually performing
• It executes network-delivered code without auditability
• It puts the user at the mercy of security decisions made by others
• Network delivered code can be poisoned in a variety of ways, including network API vulnerabilities, hijacked domains, malicious detection of curl … | …

The subtly more bit: false negatives. Users or orgs might have a policy of aliasing these package manager commands to harden or restrict them for their own usage. If an environment isn’t properly provisioned, this would undo those restrictions rather than failing as expected.

Solutions/prior art

NPM 7, thankfully, introduces a prompt when using npx to ask if the user wants to download and execute commands that aren’t already available on $PATH. This isn’t a panacea, but it’s a meaningful improvement over silently downloading and executing third party code.

The same technique could be used here. The downside is it’s a minor inconvenience, but the risks it would help to alleviate are huge.

Considerations

• Automations aren’t interactive, and may expect to be able to bypass this
• Meaningful thought should be put into mitigation of risk around that

in China

❯ yarn --version
Internal Error: Error when performing the request
    at ClientRequest.<anonymous> (~/.nvm/versions/node/v16.13.0/lib/node_modules/corepack/dist/corepack.js:3937:20)
    at ClientRequest.emit (node:events:390:28)
    at TLSSocket.socketErrorListener (node:_http_client:447:9)
    at TLSSocket.emit (node:events:390:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

I wonder if it would be possible to have a feature similar to python -m pip to access the package manager binaries without having them on the path. It would be useful in case the binary name clashes with another program. That could potentially address the concern of "How Corepack scales if there's 1000 package managers added to it, each package manager adding 100 binaries to the path?".

The API could look something like:

> corepack yarn install

wdyt?

Add corepack run with the same behavior as [npm|yarn] run to reduce the necessity of a package manager to run user-defined scripts in the package.json. e.g. with this start script

"scripts": {
  "start": "node index.js"
}

we don't need a package manager to run:

$ corepack run start

Also, we should add the Corepack's wrappers (npm, pnpm and yarn) to the PATH automatically. Achieving the same effect like corepack enable but only on the context of the command execution to support scripts like the following:

"test": "npm run env:test && jest",

Without adding the package managers as global commands.

https://github.com/pnpm/pnpm/releases/tag/v7.0.0

pnpx is now just an alias of pnpm dlx.

If you want to just execute the command of a dependency, run pnpm . For instance, pnpm eslint.

If you want to install and execute, use pnpm dlx .

Now I cannot run a pnpx command inside an npm configured project even though it installs the package in the global.

I need it because I need to run the following command:

pnpx -y npm@latest-6 install

Otherwise, npm v7+ will upgrade the lock file which is unwanted for projects that I cannot control.

I cannot use npx either because npx will always use the installed version of npm v8 and ignore the latest-6 I specified.

Ideally, the utility would include the requirement that package manager distributions are signed, with the ability for users to verify the signature on installation.

Corepack assumes that a package manager executable file has ".js" extension:

https://github.com/nodejs/corepack/blob/main/mkshims.ts#L25
https://github.com/nodejs/corepack/blob/main/config.json#L37

But the latest pnpm executable file has ".cjs" extension:

pnpm/pnpm#3305

$ corepack prepare --activate [email protected]
Preparing [email protected] for immediate activation...
$ pnpm
node:internal/modules/cjs/loader:944
  throw err;
  ^

Error: Cannot find module '/Users/ykoma/.node/corepack/pnpm/6.3.0/bin/pnpm.js'
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:941:15)
    at Function.Module._load (node:internal/modules/cjs/loader:774:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:76:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Given that corepack is disabled by default, how does one package it for a distribution. Specifically, corepack enable creates symlinks to /usr/bin directly.

This is problematic since

• It requires superuser access
• It overrides the file managed by distro package manager

Is it safe to create symlinks directly to pnp[mx].js and yarn[pkg].js ? Or is this subject to change over time?

The node.js installer on windows (*.msi) will choose C:\Program Files\nodejs by default to place node.exe, npm and corepack. As you may know this place requires admin permission, the installer will bring up the UAC and ask for it once.

At the same time, npm (and pnpm) works well here because it will install packages to %appdata%\npm, where no permission is needed.

However, corepack will install pnpm to the same place as corepack by default (which is C:\Program Files\nodejs\node_modules\corepack. This causes permission issue:

> corepack enable
Internal Error: EPERM ....

A workaround is using --install-directory to manually change the install folder to some place without permission, for example %appdata%\corepack.

I hope corepack would use places like %appdata%\corepack on windows to avoid potential EPERM issues.

(BTW, the node.js installer for other systems are likely to choose a place with high permission. It is really an issue on macOS because it generally forbids installing anything globally, in which case users must use brew to correctly install it to a safe place. However I'm not expecting you to fix the installer logic and this is out of scope.)

Right out of the gate, this is my first interaction on a public repository, so feel free to throw some feedback at me.

Basically i would like for corepack to automatically add the yarn's bin directory to path, so globally installed packages can be used from PowerShell | cmd without any hassle.

This is not a behavior on windows, can't test on different OS right now.

Perhaps when the corepack enable command is used this action could be triggered, so it doesn't make any unnecessary changes for those not using corepack.

Alpine v3.15
Node v16.13.0

corepack is not installed?

This thread is meant to discuss the init workflow. For example, what happens when running yarn init or npm init? Under the current model those commands will fail, because pmm is implemented in such a way that the package.json is created before spawning the process, which will then detect the preexisting manifest and refuse to update it.

Here's what I tried:

• Install Node.js 16
• Run corepack enable
• Run pnpm --version, it prints "6.11.0"
• Run echo '{ "packageManager": "[email protected]" }' > package.json
• Run pnpm --version again, this time it prints "6.24.0"

I think this feature is great!

However, the fact that there is a silent installation that takes 4x longer to run pnpm --version is a bit worrisome and unexpected.

I think corepack should print something when its installing a new version so its clear that something is happening in the background. And perhaps even print where its installing to. (Related to #55)

The readme leaves me clueless, the https://github.com/nodejs/corepack/blob/main/DESIGN.md says it is "engines": {
"pm": "yarn@^2.0.0"
} and the node doc says {
"packageManager": "@"
}
so which one is it ?

I run nvm-windows and have had a few users trying to use Node 16.9.0 with corepack. It's not currently clear how this will be shipping for Windows, and there don't appear to be any builds for Windows at https://github.com/nodejs/corepack/actions/runs/276463953. As it currently stands, it appears the only way to use corepack on Windows is through an npm global installation.

In case it helps, here is some background info about how version management is handled on Windows:

Currently, Windows version managers source node and their associated npm versions from https://nodejs.org/dist/index.json. The paths are derived using the zip archives from each of their respective repos (i.e. https://nodejs.org/dist/) and https://github.com/npm/cli/archive/ respectively. There is no special installation process for any version of Node. In NVM4W, a symlink is configured to point to the appropriate version, then it remains hands-off.

If corepack is going to work with version managers, it cannot be reliant on the Node installer. The Node installer is not used in version managers on Windows (this is true for Nodist as well) because it uninstalls prior versions and fails if a newer version already exists. In other words, it only allows one version to be installed at a time. See nodejs/node#4603 for details. For npm, NVM4W currently copies the npm/npx commands to the node root, making them accessible as global commands. If corepack shipped a bootstrap command like this, we could do the same thing.

Bottom line: I'm trying to figure out how to bootstrap corepack so Windows recognizes it for the active version of Node.

It'd be a good idea to have a GH Action scheduled on a daily run that would check the latest package manager version and update the config.json file accordingly, before publishing a new release.

Hi,

What is the status of this project ?

We can read on the README.md

we're working with the Node TSC to provide Corepack by default starting from Node 15, thus ensuring that all package managers can be used with little to no friction.

But it seems not be embedded into Node 15 ?

There is some plan for Node 16 or more ? Or this project is it currently dead ? (last commit some months ago, and some CI tests have failed https://github.com/nodejs/corepack/runs/1227988760 )

Thanks in advance for your answer :-)