yarnpkg / berry

📦🐈 Active development trunk for Yarn ⚒
https://yarnpkg.com
BSD 2-Clause "Simplified" License
7.34k stars 1.1k forks source link

[Feature] reconsider prepare lifecycle script? #2967

Open typicode opened 3 years ago

typicode commented 3 years ago

Describe the user story

As a developer, I may need to run some development only postinstall script.

Describe the solution you'd like

Enable prepare script.

Describe the drawbacks of your solution

I'm aware Yarn 2 tries to simplify and limit the number of lifecycle hooks. I think it's good a thing.

However, except with some tricks and AFAIK there's no way to have a development only postinstall script with Yarn 2.

Describe alternatives you've considered

Since only postinstall can be used to run commands after yarn, I've created pinst as a way to disable it when a package is published (simulating a dev-only postinstall script).

There's an example here: https://typicode.github.io/husky/#/?id=yarn-2

sachinraja commented 3 years ago

I believe I've solved this with a simple plugin, yarn-plugin-postinstall-dev. This should run only when the developers run yarn install. Though this should definitely be supported without plugins.

merceyz commented 3 years ago

With https://github.com/yarnpkg/berry/pull/3146 merged pinst should be able to remove the postinstall script before packing again, we could potentially support overriding lifecycle scripts in publishConfig to have a development only postinstall as well

rxliuli commented 2 years ago

I believe I've solved this with a simple plugin, yarn-plugin-postinstall-dev. This should run only when the developers run yarn install. Though this should definitely be supported without plugins.

There are some errors in this script, but I modified it slightly and it can be used normally.

node:events:371
      throw er; // Unhandled 'error' event
      ^

Error: spawn yarn run postinstallDev ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (node:internal/child_process:288:12)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'spawn yarn run postinstallDev',
  path: 'yarn run postinstallDev',
  spawnargs: []
}
sachinraja commented 2 years ago

@rxliuli Please create an issue on the repo as this is not the right place to report issues with it

paescuj commented 1 year ago

I agree with @typicode that Yarn's initiative to simplify and limit the number of lifecycle hooks is generally a good thing. But IMO the "prepare" lifecycle script is pretty essential. The docs of Yarn itself are recommending to avoid the "postinstall" script whenever possible: https://yarnpkg.com/advanced/lifecycle-scripts/#a-note-about-postinstall However, without the "prepare" script there is currently no (clean) alternative for tools like husky or simple-git-hooks.

I'd really appreciate some thoughts / feedback from the maintainers here! I'll be happy to come up with a PR if this request is accepted!

WoodyWoodsta commented 1 year ago

To add a use case to this issue: we share git hooks among the team, which perform some important checks before commiting. In order to make these checks more watertight, it's best that it's not left up to the development to configure the hooks path. With NPM, we would use the prepare lifecycle hook as the place to setup the git hook changes, but we now no longer have an out-the-box solution.

macbem commented 1 year ago

I second this. It would be useful to bootstrap auth for our private package registries since the getNpmAuthenticationHeader plugin lifecycle hook is ran in parallel and it's not feasible to add sign-in logic there. It would be useful to have a prepare hook that would allow us to run sign-in logic and tokens would be available for extraction when packages are requested. Without this lifecycle script, the only viable option I see is to wrap yarn install with a custom script which doesn't sound like a good solution tbh.

Devidian commented 1 month ago

I like yarn, i like typia, i like to work with latest updates. Sadly typia needs prepare script and berry doesn't support it. So typia doesn't support berry. That makes me sad, because i cant stick up to latest version.

Oh well, that is maybe just a +1 with an usage example from my side.

blimmer commented 1 month ago

This is a bigger problem now that NPM has broken the pinst workflow, which is what everyone using husky on Yarn Berry uses.

See https://github.com/typicode/husky/issues/1491 / https://github.com/typicode/pinst/issues/23 / https://gist.github.com/djcsdy/2f5a287b3ba16f2a8f0312f45588e6ce

TLDR; we really need a lifecycle script that only runs when running yarn install on the package in question.