Don't run the pre/post scripts

[zkochan]

NOTE: It is possible to return how pre/post scripts worked by setting the enable-pre-post-scripts setting to true (since v6.1.0)

---

When running pnpm run foo, don't run the prefoo script and the postfoo script.

Yarn 2 already deprecated the pre/post scripts:

In particular, we intentionally don't support arbitrary pre and post hooks for user-defined scripts (such as prestart). This behavior, inherited from npm, caused scripts to be implicit rather than explicit, obfuscating the execution flow. It also led to surprising executions with yarn serve also running yarn preserve.

https://yarnpkg.com/advanced/lifecycle-scripts

[aminya]

Does this affect postinstall as well? Because many packages use postinstall to perform operations that are not covered by the package manager (such as copying fonts, building, etc). In my opinion, not running that is not a good approach!

[zkochan]

no, the standard lifecycle scripts like postinstall or prepublishOnly are not affected.

[zkochan]

but prepostinstall will not be executed. And postpostinstall as well.

[Djaler]

Is there are a way to enable it again? I think this is useful feature in some cases

[zkochan]

I don't see much value in it. You may just add "start": "pnpm prestart && node server.js" if you need it.

It is not some action that you do frequently. Mostly you just add a script once and never change it.

[Djaler]

Makes sense

[TigersWay]

I don't see much value in it. You may just add "start": "pnpm prestart && node server.js" if you need it.

It is not some action that you do frequently. Mostly you just add a script once and never change it.

May I disagree?
Nearly all my scripts have been written with these "pre" & "post" hooks to deal specifically with env variables or clean actions. And I know I am not the only one.
Just to be clear I honestly don't care what yarn is doing!

[Heartnett]

I agree with @TigersWay! From my side: I don't want a yarn clone.

[cdaringe]

if you need pre/post, you can get similar ergonomics + explicitness (which this changes aims to acheive) with https://github.com/mysticatea/npm-run-all (run-p/run-s)

[Heartnett]

if you need pre/post, you can get similar ergonomics + explicitness (which this changes aims to acheive) with https://github.com/mysticatea/npm-run-all (run-p/run-s)

@cdaringe does npm-run-all even work with pnpm?

[TigersWay]

@cdaringe does npm-run-all even work with pnpm?

npm-run-all does work, yes.
But pre/post hooks somehow allowed "multiline" scripts. And there, npm-run-all is no use!

[davidenke]

What a mess, this behavior is different to npm and (at least for me) unexpected.
It would make sense to have at least a flag (like --run-scripts) to restore the default behavior.

[jmcdo29]

When working with Typescript projects, prebuild is a very common script I work with to rimraf dist and while I can add that to the build script it would be nice to allow the prebuild to work directly. I'd be happy to try and figure out how we can make this work via a config or something so we can add it back in.

[cdaringe]

What a mess ...

@davidenke, wrong attitude. you realize this software is offered to you for free? this unhelpful feedback is not welcome.

@jmcdo29, here's a demo of a setup that could work for you.

{
  "scripts": {
    "compile": "tsc index.ts",
    "serve": "node index.js",
    "start": "run-s compile serve"
  },
  "devDependencies": {
    "npm-run-all": "^4.1.5",
    "typescript": "^4.2.4"
  }
}

to see it in action, you can copy and paste the following command right into your terminal and run it! (assumes you are on a mac or *nix system)

export DIR=/tmp/pnpm-scripts-demo \
 && rm -rf $DIR && mkdir -p $DIR \
 && cd $DIR \
 && echo "console.log(1+2)" > index.ts \
 && echo '{"scripts":{"compile":"tsc index.ts","serve":"node index.js","start":"run-s compile serve"},"devDependencies":{"npm-run-all":"^4.1.5","typescript":"^4.2.4"}}' > package.json \
 && pnpm install \
 && pnpm start

$ pnpm start

@ start /private/tmp/pnpm-scripts-demo
> run-s compile serve


> @ compile /private/tmp/pnpm-scripts-demo
> tsc index.ts


> @ serve /private/tmp/pnpm-scripts-demo
> node index.js

3

[jmcdo29]

I understand it could work, was just hoping to not have to add another dev dependency and work with yet another package. But if that's what I have to do then so be it.

[jmcdo29]

For what it's worth, this might be something good to document on the pnpm run page, as, up until v6 to my knowledge, pnpm mirrored npm's functionality, including running pre/post scripts of custom commands. As npm v7 still supports this, it's definitely a bit divergent from what I thought the functionality would be. I know the mention is in the changelog, but it would be nice to have it documented in the docs page as well, to help make it clearer. Just my two cents.

[TigersWay]

@cdaringe I'm sorry to share @jmcdo29's idea about the "mess" which is for me still a somehow polite word. We are here part of this community and any of us can be surprised with such a change.
Even so, "npm-run-all" is not exactly s solution: it's not maintained anymore and have some pretty bad bugs which are going to be a pain for this "unneeded" but forced transition.

[cdaringe]

idea about the "mess" which is for me still a somehow polite word.

In other words, "someone did something I don't agree with, so I can be rude." Insults and negativity--especially over something offered for free--are never productive. Consider sending patches, proposing solutions, debating pros and cons, etc.

Complaining like this rude, and helps no one. Most of us are taught this from a young age, as it has nearly global acceptance, across cultures. For reasons not yet clear to me, software engineers, in issues trackers that are not their own, feel comfortable waiving this value in favor selfishness.

Consider productive & helpful questions like:

• "<authors>, is it a design goal of yours to have parity between pnpm & npm? If so, do you see this as a violation?"
• "<authors>, do you agree or disagree that lifecycle hooks are helpful? is removing them more hurtful than helpful?"
• "<authors>, is the yarn teams' analysis and decision justifiable, or could they be over-reacting to to edge cases?"

[TigersWay]

@cdaringe

• Again, I believe that in most area in this world, "mess" is not a rude word.
• Free does not mean "accept and shup-up".
• Before trying to give advice, have a look around to see if (maybe) all what you believe should have been done, has not been done already.
• This issue means simply that some dev are going to re-think their logic, their tools, their hopes.

And these was of course my last words here.

[jmcdo29]

@cdaringe maybe I'm missing something here. Yes there was a complaint about the functionality, but it wasn't just absurdly rude. Perhaps "mess" means something different to you than how I'm reading it. Either way, the dev did mention why they thought this (it's different than npm and unexpected) and mentioned a possible solution (using a --run-scripts flag to possibly allow for running these scripts).

You're right that in open source, complaining never gets anywhere, trust me, as a maintainer of NestJS and a few other packages I get that. It's one of the reasons I mentioned at the very least this should be well documented.

pnpm stands for performant npm which is why so many of us are confused at this different functionality. If this is a design goal of pnpm, to be like npm, then this definitely would be something that is no longer aligned.

I see where the yarn team is coming from (at least in regards to running accidental scripts), so maybe instead of just pre and post we could use something like pre: and post: to help avoid preserve from being ran.

As I mentioned in my first comment on this thread I do find great use in these lifecycle scripts, and have been chasing why I've been having CI failures recently until I found that these scripts are no longer running. Now, it's my fault for using @latest of the pnpm GitHub Action, but it was still a shock to see to say the least.

[zkochan]

I was not personally offended.

We for sure need to document it prominently.

If this is a design goal of pnpm, to be like npm, then this definitely would be something that is no longer aligned.

To some extend. pnpm was named before Yarn existed😀 We try to pick the good ideas from both npm and from Yarn. And sometimes have our own way.

This change aligns with our philosophy of being strict and explicit.

We can come up with some features to make it easier. My personal favorite would be to bundle something like npm-run-all with pnpm (which we were already asked for). But I am a bit afraid to include too much functionality into pnpm. I'd personally prefer to recommend some alternative script runner for advanced usages. This pre/post doesn't seem too much of an issue for now (and this is also the feedback that I recieved from Yarn's maintainer).

[CEbbinghaus]

This topic has been argued about a lot but I wanted to voice my opinion on the matter since pnpm is a tool that I am passionately using and the only thing I dislike about it is the fact that it doesn't have more widespread adoption.

Removing the implicit pre[scriptname] hooks is an excellent idea since the original npm behaviour is extremely wrong. "preserve" is the example brought up the most but there are so many different reasons why this is bad (see Fortran's implicit none).

However, outright removing them and adding the configuration option I think is a bad solution too. The issue isn't their existence but their implicitness. The configuration should certainly be kept for backwards compatibility (to further grow pnpm as a drop-in for npm).

But I agree with @stalniy and @jmcdo29 that the right approach is to simply remove the implicit nature by explicitly defining it as pre:[scriptname]. This removes the possibility of any conflicts with the English language and clearly delimits the pre and post scripts as being in their own folder (if thinking of the colons like slashes in a path). It would also clearly state that they are "reserved" script namespaces for the lifecycle events.

I love all that the PNPM team have done and I really hope to see this added. Since currently our two options are "use a third party script runner and define the behaviour yourself" and "use a configuration option that enables the bad implicit behaviour"

Edit: added more Fortran examples and some words

[zkochan]

Adding pre: and post: sounds fine.

[shellscape]

I would like to note that it would be a breaking change for anyone that had scripts named with those prefixes or other purposes. so that should probably be an opt-in

[CEbbinghaus]

I would like to know that it would be a breaking change for anyone that had scripts named with those prefixes or other purposes. so that should probably be an opt-in

Knowing how many people's environments would break would be an extremely valuable metric for deciding on wether this change is too big of a change.

However, I believe that the removal of the implicit hooks has had a significantly greater impact than the addition of pre: and post: prefixes could possibly have since those would have to have been implemented manually by the developer (and would likely have had the same logic as what is being proposed)

Edit: some words

Adding this as an Edit so no extra notifs are sent out but a perfectly acceptable alternative way would be a postfix of :pre so [script]:pre or [script]:post. Its easier to keep it a prefix since that is what npm does as well and it only requires a single character to move to pnpm however there is an argument to be made that the "pre" and "post" scripts are "children" of the script and therefore should live in "directories" under the parents (when using my directory analogy).

Also, the Colon has already taken off as the de facto way of deliminating scripts as seen by the very package.json#L11 that runs this project.

[stabai]

no, the standard lifecycle scripts like postinstall or prepublishOnly are not affected.

It would be nice if the documentation covered exactly which scripts are standard lifecycle scripts that are not affected. I happened to care about postinstall, so my question is answered from this thread, but it's not super clear from the documentation that even this is true: https://pnpm.io/cli/run#differences-with-npm-run

[slavafomin]

Ouch! This has seriously exploded me in the face today after migrating from npm to pnpm. I was expecting pnpm to be compatible with npm...

[beenotung]

@slavafomin you can use pnpm for installation and still use npm for running scripts

[maczyt]

configure enable-pre-post-scripts=true in .npmrc is work for me

[basememara]

Ouch, surprised by this too since impression was it has parity with npm.

Added this to the docs since migrations could be severely messed up: pnpm/pnpm.io#495

[beenotung]

I think it will make less surprises if pnpm switch the configuration from enable-pre-post-script to disable-pre-post-script.

[shellscape]

agreed. every single one of my repos has that turned back on.

[tombohub]

GTP:

Mental models serve as the mind's map, charting the terrain of our expectations and experiences to navigate the world more effectively. They help us predict how systems should work, like expecting scripts named pre and post to automatically run before and after a command in package management tools. However, when pnpm deviates from this convention by disabling pre and post scripts by default, it's akin to finding a suddenly missing bridge on a well-traveled route—jarring and disorienting, forcing us to recalibrate our mental maps and adapt to this unexpected twist in the script.

[zkochan]

It will be reverted in v9

#7634