Check that dependencies are install before running scripts

[Nick-Mazuk]

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

It's easy to begin development with the wrong dependencies installed. Here's some examples:

• Switch branches, where the new branch has different dependencies
• Pull the repo for the first time

Describe the solution you'd like

Normally you'd have to remember to run pnpm i in these scenarios. I'd like pnpm to "remember" for me.

Before I run a script in the "scripts" field of the package.json (or pnpm test, etc.), I'd like pnpm to check that the correct dependencies are installed then either:

• Error out, notifying me that I should run pnpm i
• Automatically install the dependencies for me (i.e., run pnpm i in the background).

Describe the drawbacks of your solution

• This will increase the latency of every command. It may be possible to utilize caching to speed this up for subsequent pnpm invocations.
• Automatically running pnpm i can pose security risks (because postinstall scripts can run arbitrary code), so doing this should be opt-in on the developer-level in my opinion.

Describe alternatives you've considered

Keep the status quo.

[KSXGitHub]

Since automatically install dependencies could pose security risks, how about just check if the lockfile is up-to-date?

If the lockfile is out-of-date (either because it doesn't match package.json or it is different from node_modules/.pnpm/lock.yaml), pnpm would print an error to remind you to run pnpm install before running a script. This should be sufficient to prevent users from running scripts with outdated packages.

What do you think?

[Nick-Mazuk]

That's good enough for me.

[zkochan]

The issue with this is that pnpm run has already a slow startup and this will make it even slower. Unless you come up with some really smart caching mechanics to avoid reading and parsing the whole lockfile every time, which is usually a large file.

[KSXGitHub]

Unless you come up with some really smart caching mechanics to avoid reading and parsing the whole lockfile every time, which is usually a large file.

I plan to only run this validation on the very first pnpm run by setting an environment variable named pnpm_run_skip_deps_check (is this a good name?). This way, only pnpm run issued directly by the user will check the lockfile settings. Nested pnpm run will not do so.

Furthermore, this feature will be disabled by default.

[zkochan]

It isn't enough to check if the lockfile is up-to-date. You also need to check if node_modules is up to date, which can be done by comparing node_modules/.pnpm/lock.yaml to pnpm-lock.yaml.

During install I would store somewhere the modification times of package.json files and lockfiles and then during run I guess you could consider everything up to date if the modification times didn't change. Hopefully this would be fast enough as you'd only need to read attributes instead of reading and parsing big files. Although in a big workspace you'd need to read attributes of many package.json files in many workspace projects.

[zkochan]

With all the above optimizations that I suggested one expensive operation remains: searching for all the workspace projects in the filesystem. To verify that the lockfile is up to date we check if the set of workspace projects remains the same.

[KSXGitHub]

I didn't expect that this feature would be so complex. But the PR is done.