Allow running custom commands in `preinstall_node_modules` prepare script.

[AleksanderGondek]

Is your feature request related to a problem? Please describe. Oftentimes, linking binary under module /vendor directory is not enough to make it compatible with execution on NixOS / under nixpkgs.

Consider the following, real-world example:

1. Developer is working on NixOS
2. A node project exists, which requires an esbuild module in two distinct versions (each module does a strict version comparison check for the binary in post-installation step).

Due to [1] the default installation path will fail - there is no pre-built binary for NixOS which may be readily downloaded from the npm cache. Binary has to be provided in another way.

To the best of my knowledge, the only feasible way of doing so in the aforementioned module is via setting ESBUILD_BINARY_PATH environment variable. However, as this variable name is common for the node_module environment, one cannot separate provisioning of binary in version X for module X and binary for version Y for module Y (requirement of [2]).

Even if, one assumes the esbuild module would allow for simple dropping in of binary to vendor subdirectory, the issue would still not be solved, as preInstallLink attribute does not differentiate between node module versions.

Consequently, without a way of running some arbitrary customization per module per pinned version, one cannot possibly ensure that all node modules will install successfully.

Describe the solution you'd like I would like to introduce to node_modules an attribute, which would allow for executing arbitrary shell commands per node module in a given version.

For example:

preInstallCustomCommands = {
   “[email protected]” = [
       “echo ‘Who are you, who are so wise in the ways of science?’;”
   ];
};

Would echo the message only for esbuild node module in version X.Y.Z, during the prepare script execution.

Describe alternatives you've considered

• Using preInstallLink to override whole files from node module definition (for example install.js) - this however still does not solve the problem of being blind to module version

Additional context I have come across the issue of multiple versions of a single, ill-build node module, while trying to enable the tweag\www repository to be built on NixOS.