berry icon indicating copy to clipboard operation
berry copied to clipboard

[Feature] reconsider prepare lifecycle script?

Open typicode opened this issue 4 years ago • 9 comments

  • [ ] I'd be willing to implement this feature (contributing guide)
  • [ ] This feature is important to have in this repository; a contrib plugin wouldn't do

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

typicode avatar Jun 02 '21 00:06 typicode

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.

sachinraja avatar Aug 02 '21 20:08 sachinraja

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

merceyz avatar Aug 17 '21 09:08 merceyz

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: []
}

rxliuli avatar Sep 23 '21 11:09 rxliuli

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

sachinraja avatar Sep 23 '21 12:09 sachinraja

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!

paescuj avatar Jan 03 '23 13:01 paescuj

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.

WoodyWoodsta avatar Mar 27 '23 12:03 WoodyWoodsta

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.

macbem avatar Mar 27 '23 13:03 macbem

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.

Devidian avatar Jul 19 '24 07:07 Devidian

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.

blimmer avatar Aug 07 '24 16:08 blimmer

Hey there! I was wondering if the Yarn team has given any thought to this matter?

RomainLanz avatar Dec 12 '24 10:12 RomainLanz