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
- 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.
- 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.
- 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.
- 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.
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 hasallow-scriptsin their user.npmrc, and neither failure mode is mentioned in the README.Installing should be a single command with no manual repair step.
Environment
github:johncwaters/glissa)Problem 1: node-pty is left uncompiled, and the install still reports success
Exits 0 with
added 75 packages, then warns: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 blockednode-ptyscripts matter:build/Releasenever getsconpty.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:
After that,
require('node-pty')loadsprebuilds/win32-x64/pty.nodeand a real pty spawn round-trips correctly (exit code 0, expected output).glissa doctorthen reportsnode-pty loads OK.Note that
--allow-scripts=node-ptyon the install command is not a workaround here, for the reason in Problem 2.Problem 2: any
allow-scriptsconfig kills the git install entirelyWith
allow-scripts=node-ptyin~/.npmrc(a natural thing to have, since that is what npm suggests for global installs of native modules), the documented command fails completely:A git-source install spawns a nested project-scoped install to build the package. npm 12 refuses
allow-scriptsin that context, and the nested install inherits the setting from the user-level.npmrc, so preparation dies. Passing--allow-scripts=node-ptyon the command line fails identically, because the setting propagates into the nested install too.The only way through is to have no
allow-scriptsin effect anywhere, which is precisely the opposite of what Problem 1 needs. Removing the line from~/.npmrcwas required before the install would run at all.Failed attempts also leave a partially populated
node_modules/glissabehind that npm cannot clean up (EPERM ... rmdir node-pty/deps/winpty,@xterm/xterm/src/vs/base), so retries need a manualrm -rfof the global package directory first or they build on top of debris.Suggested fixes
package.jsonvia theallowScriptsfield npm's error message points to, so a normal install compilesnode-ptywithout the user passing flags. This looks like the mechanism intended for exactly this case, though I have not confirmed npm honors a package'sallowScriptsfor its own dependencies during a global install; worth validating before relying on it.glissa doctoralready checksnode-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.--allow-scriptsmust 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.