Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'corepack prepare' does not read "packageManager" in package.json #96

Closed
brandon-leapyear opened this issue Mar 14, 2022 · 4 comments · Fixed by #99
Closed

'corepack prepare' does not read "packageManager" in package.json #96

brandon-leapyear opened this issue Mar 14, 2022 · 4 comments · Fixed by #99

Comments

@brandon-leapyear
Copy link

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": "yarn@3.0.2"}' > 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)
@kylemh
Copy link

kylemh commented May 17, 2022

Hey @arcanis

I think fixing this introduced an issue that's worth resolving. If have the packageManager set, but then run a prepare command with a specific version listed, the value is silently ignored and the packageManager value is adhered to. I think it'd be better for the command to fail with a helpful error or at least provide a logging statement to be less silent about the mistake.

@kherock
Copy link
Contributor

kherock commented Jun 1, 2022

@kylemh I don't think this fix has been released yet, unless you have a configuration where you're running corepack from source. Keep in mind that, when defined, packageManager is always adhered to when using corepack yarn, corepack pnpm, etc. To change the package manager version that a project uses, I think you're expected to edit package.json and commit the update.

@kherock
Copy link
Contributor

kherock commented Jun 1, 2022

The docs for corepack <binary name>[@<version>] [... args] kind of dances around this fact:

Note that those commands still check whether the local project is configured for the given package manager (ie you won't be able to run corepack yarn install on a project where the packageManager field references pnpm).

@kylemh
Copy link

kylemh commented Jun 1, 2022

I am installing in CI and using it from source because I'm on Node 14.

What you're saying is totally fair, and I gathered as much... but only after a lot of investigation. There's nothing wrong with the logic, but the CLI logging offers no notice. I guess I'm suggesting that the config "winner" gets an announced in the output of a ran command.

This isn't a question about docs either. I didn't go to corepack docs because I had no CLI errors or logging which indicated implicit behavior was intercepting my explicit command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants