Bringing back preupdate and postupdate

[muuvmuuv]

I am working in a large Angular project and would like to take some process off the shoulders of our employees by doing jobs before and after common npm scripts. Let's say someone installs our project the first time, we will display a little welcome message and setting up the environment for the installation, like running nvm, after the installation we remind about the README and how to contribute and settings up git-flow. This is just great and helps a lot!

Now we would like to do the same for the update process. Normally some experienced user would do that and update dependencies but it would help to for example remind that user that before running npm update he should consider using ng update because if migrations are going to take place they should ideally be before updating all dependencies. Same goes for after the update, there I would like to do things like running tests to prove the update succeeded without errors or run some GraphQL Schema generation.

From the discussion (issue) in the old repo here it definitely makes sense to me why it has been deactivated but I would like to find a solution that will make everyone happy. Even if we say we move to Makefile (which we already use for building the project) with the update process, I would like to exit the npm update process with a notice before someone makes a mistake and pushes none migrated code (not everything can be tested through CI).

[isaacs]

Yeah, would be pretty easy to add {pre,post,}update script hooks. No objection from me. 👍

[ruyadorno]

Hi @muuvmuuv 😊 Thanks for the idea!

We discussed it briefly during our last OpenRFC meeting and the consensus is that this is a good idea. Since it's such a small change it doesn't warrant a full RFC so instead I opened up an issue over Arborist: npm/arborist#172 so that we can track it. 😄

[muuvmuuv]

That is great 🥰 thank you

[isaacs]

So, looking at this a bit closer, the feedback in that old issue does kind of still make sense. I'm fine with adding {pre,post,}update script support, but it raises some interesting questions.

If you do this, for example:

npm i abbrev@1.0
npm i abbrev@latest

vs this:

npm i abbrev@1.0
npm update abbrev

or this:

npm i abbrev@1.0
npm update

the outcome is the same in all three cases. We will replace node_modules/abbrev at version 1.0.0 with abbrev@1.1.1.

If you have something that you want to run whenever deps are updated, you probably want to have it run in all three cases, but only the second and third will go through the "update" path. There is no script for "run at the root level before updating a dependency", and adding one presents some challenges. The practical challenge is that deps are resolved in one place, and reified in another, and only at the reification step do we bother to calculate the difference from the actual and ideal dep trees.

Fair enough, we could run the script there. However, should this script be run only for top-level deps, or for all deps within the tree?

Say for example, you install foo which depends on bar@^1.1.0. You already have bar@1.0.0 to satisfy a root level dep on bar@1.0.x. Then, bar@1.1.1 is published.

You run npm update bar. This will update node_modules/foo/node_modules/bar, but not node_modules/bar (because 1.1.1 doesn't satisfy the root level dependency). Should we run the script then?

Also there's a question of whether we run it one time at the top level to say "deps are being mutated", or once for each dep being mutated.

Now let's say the root dep is bar@1.x and you install it when the latest is bar@1.0.0. Then bar@1.1.0 is published, and you install foo in such a way that it has to nest the dep (either because something else was depending on bar@1.0, or because you used --global-style to nest foo's deps). Then, you remove the thing that was holding bar@1.0.0 in place, and run npm update bar. This will update node_modules/bar to 1.1.1, and remove node_modules/foo/node_modules/bar (since it's no longer needed). Should we run the script once, or twice?

Let's say you're starting from an empty node_modules folder and no package-lock.json file. You run npm install react webpack gatsby babel. Should we run the update script 2000 times, or just once?

Running for every change is pretty onerous. But if we just run it one time, you don't have much ability to know why it's being run, which limits the utility somewhat.

I think this is worth writing up a proper RFC about, just so that we can be sure to go through these issues and reduce the chance that we are tied to supporting (yet another, lol) regrettable approach.

[isaacs]

If it's just "run this script once if the user runs npm update, and not other times", well, that's pretty easy, but I'm not sure it satisfies the needs described in the OP.

[muuvmuuv]

Yes, I mean in all cases. In my particular use-case you would do npm i @angular/core@latest which should throw something or at least have a big hint that migrations might be available.

[oliverfoster]

I can't find any reference to preupdate and postupdate, aside from this discussion. Is this still planned?