v0.3.4
Build the engine specifier instead of writing it inline
The publish guard refused the package:
dist/RosettaProvider.js imports @c9up/inker at runtime
It is right to. This package declares zero runtime dependencies and
verify-package.mjs proves the claim rather than trusting the manifest:
an optional peer that reaches the emitted JavaScript is a runtime
dependency whatever the manifest calls it. A literal import() is
exactly that, and it also makes a bundler try to resolve inker at build
time for an application that never installed it.
Computed through a variable, as ream's quasar bridge already does for
the same reason, it stays invisible to static analysis and still runs
only behind the usingInker flag. Guard passes, 253 tests, branches
73.52%.
Cover the engine shapes the provider dispatches between
CI failed on coverage, not on a test: branches came to 72.92% against a
73% threshold -- one branch in 1326. The uncovered ones were mine, in
the template-plugin install added when the provider stopped resolving
the engine from the container.
They were untested because the engine module mock had a single fixed
shape, and the provider duck-types between two real ones: a plugin
registrar with use(), and a live engine that only publishes globals.
A fixed mock can only ever exercise one. The mock now reads its default
export through a getter so a test can choose, which covers both paths,
the engine it recognises neither way (boot must not fail over i18n
globals), and the case where no engine is installed at all.
Also covers an emitter that answers a promise -- asserted by watching
for the unhandledRejection it exists to prevent, rather than by
asserting that nothing happened.
Branches 73.52%. 253 tests pass.
Reach the template engine through its module, not the container
The i18n globals were pushed by resolving the inker container token during
boot. That token is bound in register() and only resolvable after
start(), which every provider's boot() precedes — so the push either
threw or forced the engine to be built before its own peers were wired. In
the kitchen-sink it failed the whole application boot.
Upstream's i18n provider does not do this: it checks a flag on the app, then
pushes into the engine package's module singleton, whose use() only
enqueues. There is no lifecycle to get wrong. This now does the same, with
inker as an optional peer so an app with no template engine is unaffected.
Release 0.3.4.
Keep the dev-dependency alignment, drop the workspace: protocol
The internal ranges had been rewritten to workspace:^. That resolves inside
this monorepo and nowhere else: every package CI checks out its own repository
alone and runs pnpm install, where the protocol has no workspace to point at
and fails with ERR_PNPM_WORKSPACE_PKG_NOT_FOUND before a single test runs. The
concrete ranges are back; the dev-dependency bumps that came with the same edit
are kept, and now match what the lockfile already resolved.
Read the mustache spelling too when filling an untranslated message
The message that reaches the fallback interpolator is the VALIDATOR's own
default template, and those are written in mustache: {{ field }}. The
interpolator knew only the single-brace form an application writes in its own
catalogue, so it matched the INSIDE of the pair and left the outer braces
standing. Every rule an app had not translated yet rendered to the end user as
The {name} field must have at least {4} characters.
Both spellings are read now, mustache first so it wins on a pair.
Name the validation contract rather than the project behind it
Comments and test labels called the messages-provider contract by the name of
the library rune's shape was taken from. Parity is shape, never product
identity — and rosetta implements the contract rune publishes, which is the
thing worth naming here.
Comment and test-label only; no identifier, no runtime string.
Name the CI workflow after the package
Every workflow already declared name: <pkg>-ci inside — twenty-eight of
twenty-nine — while the file was ci.yml almost everywhere and
<pkg>-napi-ci.yml in three places, where the -napi said nothing: half the
packages with a Rust engine did not carry it.
The file now matches the name it has always had, so one rule covers every
repository and the publish command no longer depends on remembering which
three were spelled differently.
GitHub keys run history by file path, so the runs recorded under the old name
stay reachable under it and this workflow starts a fresh history.
Changes since v0.3.3.