Skip to content

Global git install leaves node-pty uncompiled and fails outright with allow-scripts in .npmrc (npm 12) #9

Description

@johncwaters

Summary

The documented install command does not produce a working install on npm 12. node-pty's native binding is silently left uncompiled, so the terminal backend is dead until the user manually runs node-pty's install scripts by hand. Separately, the install hard-fails outright for anyone who has allow-scripts in their user .npmrc, and neither failure mode is mentioned in the README.

Installing should be a single command with no manual repair step.

Environment

  • glissa 0.21.0 (installed from github:johncwaters/glissa)
  • npm 12.0.1
  • node v26.3.0
  • win32 x64

Problem 1: node-pty is left uncompiled, and the install still reports success

npm install -g github:johncwaters/glissa --allow-git=root

Exits 0 with added 75 packages, then warns:

npm warn install-scripts 2 packages had install scripts blocked because they are not covered by allowScripts:
npm warn install-scripts   glissa@0.21.0 (postinstall: node scripts/postinstall-path-check.js; prepare: node scripts/prepare-build.js)
npm warn install-scripts   node-pty@1.1.0 (install: node scripts/prebuild.js || node-gyp rebuild; postinstall: node scripts/post-install.js)

npm 12 blocks install scripts by default. The blocked glissa scripts are harmless (dist/ is already built during git preparation and packed, and the postinstall is only a PATH check), but the blocked node-pty scripts matter: build/Release never gets conpty.dll, and glissa cannot spawn a terminal. The install looks successful, so the user only finds out when the app fails at runtime.

Manual repair that fixed it here:

cd <global>/node_modules/glissa/node_modules/node-pty
node scripts/prebuild.js && node scripts/post-install.js

After that, require('node-pty') loads prebuilds/win32-x64/pty.node and a real pty spawn round-trips correctly (exit code 0, expected output). glissa doctor then reports node-pty loads OK.

Note that --allow-scripts=node-pty on the install command is not a workaround here, for the reason in Problem 2.

Problem 2: any allow-scripts config kills the git install entirely

With allow-scripts=node-pty in ~/.npmrc (a natural thing to have, since that is what npm suggests for global installs of native modules), the documented command fails completely:

npm error code 1
npm error git dep preparation failed
npm error command ... npm-cli.js install --force ... --global=false
npm error npm error code EALLOWSCRIPTS
npm error npm error --allow-scripts is not allowed in project-scoped installs. Add the entries to the "allowScripts" field in package.json, or to .npmrc, instead.

A git-source install spawns a nested project-scoped install to build the package. npm 12 refuses allow-scripts in that context, and the nested install inherits the setting from the user-level .npmrc, so preparation dies. Passing --allow-scripts=node-pty on the command line fails identically, because the setting propagates into the nested install too.

The only way through is to have no allow-scripts in effect anywhere, which is precisely the opposite of what Problem 1 needs. Removing the line from ~/.npmrc was required before the install would run at all.

Failed attempts also leave a partially populated node_modules/glissa behind that npm cannot clean up (EPERM ... rmdir node-pty/deps/winpty, @xterm/xterm/src/vs/base), so retries need a manual rm -rf of the global package directory first or they build on top of debris.

Suggested fixes

  1. Declare the native dependency in glissa's own package.json via the allowScripts field npm's error message points to, so a normal install compiles node-pty without the user passing flags. This looks like the mechanism intended for exactly this case, though I have not confirmed npm honors a package's allowScripts for its own dependencies during a global install; worth validating before relying on it.
  2. Failing that, avoid the build entirely: publish prebuilt tarballs as GitHub Releases and document installing from a release asset, so there is no git preparation step and no native compile on the user's machine.
  3. Make a missing binding loud rather than silent. glissa doctor already checks node-pty, so have the server refuse to start with the same check and print the repair command instead of failing deeper in a terminal spawn.
  4. Update the README install section to state that --allow-scripts must not be passed to the git install and must not be present in ~/.npmrc, and add the node-pty repair command as a documented step for as long as one is still needed.

Happy to test any of these.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions