v0.2.1
Accept a manager that answers only through a get trap
Quasar's service accessor is a Proxy over an empty null-prototype object with
a get trap and nothing else, so "connection" in manager is FALSE while
reading it returns the function. The probe was gated on in — added to stop a
mocked module namespace from raising on an export it does not have — and that
rejected the real manager. Only the live-Redis suite noticed, because every
unit test used a plain object.
Reading through a catch satisfies both shapes, and both are now pinned: fixing
either one alone breaks the other, which is exactly what happened.
Take the quasar loader from the vendored copy
Seven packages carried the same optional-peer loader: the runtime specifier,
the manager guard, the command check and the messages around them. Only three
things differed — the commands each issues, what it does with them, and how it
builds an error — so those are passed in and the rest is generated from
scripts/vendor/quasarConnection.ts.
Two things the packages' own tests caught while it was being unified, and both
are now properties of the shared copy rather than of one package:
The module namespace is probed with in before it is read. Reading an export a
namespace does not have is not always harmless — under a test double it raises
instead of answering undefined, so the probe failed on the mock rather than
falling through to the default export.
The error is built by the caller. nova raises NovaError with E_NOVA_* codes
that a caller catches on, and a shared helper throwing a bare Error would have
dropped them silently. Packages that offer a client object instead of a
connection name keep saying so, too: unifying the wording had removed the
alternative from the one message where it was actionable.
Take nodeEnv from the vendored copy
The file was identical to the other packages' copies, line for line, and they
had drifted apart only in their comments — each explaining its own
consequence, which is what made three identical files impossible to diff.
It is generated from scripts/vendor/nodeEnv.ts now and never edited here; the
reason this package cares moved to the decision it explains. It cannot be a
dependency: this package is published and built from its own repository, where
nothing of the workspace exists.
Find the jobs where the application is, and say when you cannot
Discovery resolved its locations against process.cwd(), so app/jobs meant
whatever directory the process started in. A worker launched from anywhere
else found nothing, and found it silently. The context takes the host's
makePath, which is what upstream provides for exactly this; a host without one
keeps the old behaviour, since bay is agnostic.
Two silences went with it. Every readdir failure read as an empty directory,
so a permission denial, a broken mount or a path naming a file produced a
worker with no handlers that accepted jobs and processed none — only ENOENT
means 'not written yet' now. And skipping a broken job file so the others
still run is deliberate, but skipping ALL of them is a broken deploy, not a
warning: discovery refuses to return nothing when every file it found failed
to load.
Changes since v0.2.0.