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

Better Corepack support #566

Closed
jonahsnider opened this issue Oct 28, 2021 · 6 comments · Fixed by #960
Closed

Better Corepack support #566

jonahsnider opened this issue Oct 28, 2021 · 6 comments · Fixed by #960

Comments

@jonahsnider
Copy link

Corepack is an official Node.js tool for managing package managers like npm, pnpm, or Yarn.
It has been bundled with Node.js versions since v16.9.

Instead of running npm i -g yarn, you run corepack enable. This places yarn + pnpm binaries (technically they're Corepack shims) alongside the node binary.

Unfortunately, switching to a new Node.js version with fnm requires you to run corepack enable again before you can use your custom package managers.

Could a configuration option (ex. --corepack) be added to automatically handle this for users?

Related: post-install hooks like in #139 could be used to run corepack enable, although it might be good to have a dedicated option for Corepack since it's going to be a very common workflow for Node.js users

@arcanis
Copy link

arcanis commented Nov 2, 2021

Would be nice if it could be run automatically - perhaps when detecting that the shims are already there?

@Schniz
Copy link
Owner

Schniz commented Nov 3, 2021

Hi! sorry for the delay.
I don't know corepack so much, so I'm sorry if my questions are stupid:

Unfortunately, switching to a new Node.js version with fnm requires you to run corepack enable again before you can use your custom package managers.

By switching to a new Node.js version you mean a fresh version after installation, or after every fnm use into a version that was already corepack enable-d?

Could a configuration option (ex. --corepack) be added to automatically handle this for users?

Where would this configuration go?

  • fnm install --corepack
  • we can also go with fnm env --install-with-corepack (and therefore emitting FNM_INSTALL_WITH_COREPACK=true, which we can use in fnm install 😃)

I think my next question would be, why shouldn't it be the default? Will it hurt to call corepack enable on all installation after a certain version?

Related: post-install hooks like in #139 could be used to run corepack enable

intriguing. Maybe we can have a $FNM_DIR/hooks/ directory that can allow executables to be fired when fnm does something:

  • $FNM_DIR/hooks/post_install{,.sh,.cmd,.bat,.exe}
  • $FNM_DIR/hooks/post_use{,.sh,.cmd,.bat,.exe}

@jonahsnider
Copy link
Author

By switching to a new Node.js version you mean a fresh version after installation, or after every fnm use into a version that was already corepack enable-d?

After a fresh install.

Where would this configuration go?

  • fnm install --corepack
  • we can also go with fnm env --install-with-corepack (and therefore emitting FNM_INSTALL_WITH_COREPACK=true, which we can use in fnm install 😃)

Both of these seem fine. Having fnm env --install-with-corepack seems helpful since you won't need to repeat --corepack over and over.

I think my next question would be, why shouldn't it be the default? Will it hurt to call corepack enable on all installation after a certain version?

Corepack is currently marked "Stability: 1 - Experimental" by Node.js and is explicitly opt-in because of this:

Due to its experimental status, Corepack currently needs to be explicitly enabled to have any effect.

Until it's more stable I don't think Corepack should be the default for fnm.

@arcanis
Copy link

arcanis commented Nov 3, 2021

I think my next question would be, why shouldn't it be the default? Will it hurt to call corepack enable on all installation after a certain version?

I personally think it could be interesting!

The main reason why it's not the default yet isn't stability per-se (as in, I'm not aware of any bugs in it), but rather that it's a little difficult to evaluate the risks for the whole Node userbase. Enabling it by default for a smaller population (such as fnm users) would be a good way to gather confidence.

@arcanis
Copy link

arcanis commented Jan 24, 2022

Friendly ping 😊

@nevir
Copy link

nevir commented Nov 26, 2022

This would be extremely helpful in making it easier to onboard new developers to fnm

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.

4 participants