Run npm prune before install.

[lijunle]

• npm prune will clean up useless packages under node_modules.
• Otherwise, the useless packages may affect normal runtime by accident.

[davidebbo]

Does it need --production to match the install command?

[lijunle]

Updated.

[davidebbo]

So I’m playing with it with ghost (https://github.com/felixrieseberg/Ghost-Azure), and it’s not behaving as I would expect.

• I run npm install --production and it gets to a stable state. i.e. if I run the same command again, nothing is installed
• But if I then run npm prune --production, it removes 3 packages:

unbuild [email protected]
unbuild [email protected]
unbuild [email protected]

• Then running the same prune again does nothing
• Then running the same install again brings back those packages

I would have expected ‘prune’ to be a no-op right after a clean install. The problem is that based on what I observed, it’s going to keep uninstalling/installing things on every Kudu deployment, no matter how small. This could cause big perf regressions on incremental deployments.

Am I misunderstanding how prune works?

[lijunle]

The issue you mentioned seems like a bug for npm itself.

I think yes to expect 'prune' to be a no-op right after a clean install. However, there is no clean install on kudu deployment.

My story: I am developing a website and deploy it to Azure. Its dependencies changes day to day. And, in some case, there is a necessary to do a clean install, for example, upgrade Babel from 5 to 6. Kudu does not provide a way to do clean install, prune seems a better way to solve this problem.

[davidebbo]

Yep, I understand your situation, and the idea of pruning absolutely makes sense. However, I'm concerned about potential regressions (perf and maybe functional) if we don't have a clear understanding of exactly what the command does. And based on the one test I tried, it does weird things and would almost certainly cause perf regressions, constantly deleting and then reinstalling packages even where there are no changes at all.

Let's try to get a better understanding of why it's doing that, and potentially open an npm bug accordingly.

Note that in the meantime, you can use a custom deployment script to have the prune command.

So again, I like the change, but I want to be careful :)