Repository navigation
v0.1.3
Fixed
-
A spawn failure is now visible to the HOST, not only to a terminal that may
not exist (#1).onErrorwas the only channel, andfancy-term-host
forwards it into the terminal data stream — correct for a pty that opened and
then broke, useless for one that never opened. In a packaged Electron app the
0.1.2 asar bug therefore leftpid -1and nothing else; it was diagnosed from
the shape of the failure rather than from anything this package said.An
errorwith no registered listener now also goes toprocess.stderr,
which is Node's own convention for an unhandlederror: do not swallow it.
It deliberately does not throw the wayEventEmitterdoes — crashing an
Electron main process over one failed terminal is worse than a loud line —
and the check happens at emit time, not atopen()time, so a caller that
registersonErroron the line afteropen()is never second-guessed and
never printed over.This changes nothing a caller can observe except that a fault nobody listened
for becomes visible. The alternatives all alteredopen()'s synchronous,
node-pty-shaped contract, which exists so consumers need no adapter change. -
A synchronous spawn failure now names the package and the path.
spawn
fails two different ways, measured rather than assumed: a directory or a
nonexistent path emits an asyncerror(ENOENT), while a non-executable
file throws synchronously (EFTYPE on Windows). The sync half already
reached the caller, but as a barespawn EFTYPEnaming neither this package
nor the file — and whoever reads that is debugging someone else's library.
Added
src/__tests__/unheard-error.test.ts. Its fixture is a directory, which
is the only construct that reproduces the real shape: theexistsSync
pre-flight PASSES and the spawn then fails asynchronously — exactly what the
asar bug did, where Electron's patchedfssaid yes and the unpatched
spawnsaid no. The first draft used a.tsfile and failed for the wrong
reason, which is how the two failure modes came to be measured.