Pin a working (tested) version of `node-gyp` so that it gets picked during the `postinstall` build

[ymeine]

Hi,

I recently tried to install node-pty into my project, but the build failed.

It turns out there has been a bug recently introduced in node-gyp 11.1.0.

I was therefore looking for a commit on your side which would have updated the node-gyp dependency recently, but the actual issue is a bit more problematic.

You use a postinstall script to perform the build. That scripts invokes node-gyp using npx, which means it will let the package manager pick any version available in the context. It would in theory be ok if you had it in your package.json dependencies, but instead it’s in your devDependencies.

In my case, using bun, it picked the latest version of node-gyp and therefore it failed. I tried with npm for the sake of a proper bug report, and it picked the version it had itself as a dependency. On my laptop it was worse: I had an uncleaned global NODE_PATH environment variable pointing to really outdated versions of node-gyp. It’s really not stable.

Proposed fix

Add node-gyp as a regular dependency?

To be honest, I don’t know if there’s a clean solution for that, but there should be a category “dependency for installation time only”. It’s really in between a dev dependency and a regular one.

Also, I don’t know if the semantics of npx are clear enough - and consistent enough across package managers - to be safely used. A resolution of the locally installed node-gyp path could be more robust.

Workaround

For now, installing an explicit version of node-gyp in a project should make it be picked by the npx node-gyp command when installing node-pty afterwards.

[savetheclocktower]

This is biting a project I use as well.

Moreover, all that command is doing is generating a compile_commands.json — which might be useful if you're actually developing node-pty, but isn't at all useful for any consumer of a package that has node-pty as a dependency.

I agree with everything that @ymeine says about the semantics of npx — it's not safe to assume it's just ambiently available! — but the easiest fix would be to remove this command from the post-install script altogether.