Releases: langsys/langsys-js-react
Release list
v0.6.7
Release v0.6.7
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.7Changes in this release
0662742
build: block publish when origin/main has commits we lack
--force-with-lease was not protecting this script. The lease compares the
remote against our remote-tracking ref, and publish.sh fetches immediately
before pushing — so a colleague's pushed commit is already 'expected' when
the lease is evaluated, and the flag authorises the overwrite it is named
for.
Reproduced in a sandbox rather than inferred: with the fetch done and the
branch diverged, 'git push --force-with-lease' reported '(forced update)',
exited 0, printed no warning, and left the colleague's release commit
unreachable from main. Verified the guard fires on divergence, passes
after a rebase, and that the colleague's commit survives the rebase path.
Two accounts have push access to this repo, so this was reachable, not
theoretical. Guard is placed before ORIGINAL_VERSION is assigned so
handle_error aborts with nothing to roll back, and is commented as
load-bearing — 'redundant with --force-with-lease' is the exact reasoning
that would reintroduce it.
Reported by the langsys-js-svelte agent after the Vue binding hit it live.
ba1aed0
build: fetch before the unpushed-commits check
I previously flagged the stale ahead-check as benign because it can only
over-report. Over-reporting is the failure. Reproduced in a sandbox:
HEAD already published (pushed from another machine or a co-maintainer)
ahead(stale) = 1 -> script proceeds
fetch
behind = 0 -> divergence guard passes (correctly: no divergence)
amend + force-push
-> the already-published commit is rewritten, orphaning any tag or
provenance attestation resolving to that SHA
Nothing looks anomalous on that path — no colleague, no divergence, no
conflict — and the destroyed commit is your own. Fetching first makes the
check read reality: ahead(fresh)=0 aborts with 'No unpushed commits found'.
That abort is correct rather than a regression: this script embeds the
version bump by AMENDING HEAD, so amending an already-published commit is
precisely the operation that rewrites published history.
Verified all three cases against the new order: published-HEAD aborts,
colleague divergence still aborts, normal release still proceeds.
Reported by the langsys-js-svelte agent, who correctly pushed back on my
earlier assessment.
623f55b
build: run divergence guard before the unpushed-commits check
Diagnostic quality only — both orders are equally safe, since the fetch
sits above both checks and every dangerous state aborts either way. They
differ in one state: ahead=0, behind=1.
old: 'No unpushed commits found. Please make your changes and commit
them before publishing.' -- sends the operator to commit work
they do not have, and invites a junk commit to satisfy it
new: 'origin/main has 1 commit(s) you do not have ... git pull --rebase
origin main' -- names the real condition and the fix
Re-verified all four cases against the new order: normal release
proceeds, colleague divergence aborts via the guard, already-published
HEAD aborts via the ahead-check, and behind-with-nothing-to-release now
reports the useful message.
Suggested by the langsys-js-typescript agent while diffing the four
publish scripts.
9d0b735
docs: name the catalog cost of bare {key} in Translate markup
The %key% guidance explained the mechanism (JSX evaluates {count} before
the SDK's walker sees the text, so interpolation breaks) but framed the
damage as broken interpolation. That understates it.
Because the evaluated value is captured as part of the phrase, each
distinct value hashes to its own content block. Measured against the
shipped tokenizeElement/generateCustomId:
{count} via JSX %count% placeholder
"You have 0 items" 31ff32bd.. "You have {count} items" 88642c82..
"You have 1 items" 5aa5eef5.. "You have {count} items" 88642c82..
"You have 2 items" 89f09f5e.. "You have {count} items" 88642c82..
So a around a live counter registers a new content block per
tick. Nothing looks wrong while it happens — the base locale renders
correctly throughout — and it surfaces later as a Translation Manager
full of near-duplicate entries.
Broken interpolation sounds like something you would catch in testing;
this is specifically the class you would not. Worth stating plainly.
Surfaced by the langsys-js-svelte agent as an aside while running the
custom_id harness; both halves measured here, including that %key%
normalizes to canonical {count} and yields one stable id across values.
README.md, src/components/Translate.tsx.
2b73c7a
docs: close the same {key} catalog gap in
Translate.tsx got this in the previous commit; Phrase.tsx had the
identical defect and was missed. Both the prop doc and the component
JSDoc explained the mechanism ("a bare {n} in JSX is an expression")
without naming what it costs.
Phrase reaches the problem by a different route, so it needed its own
measurement rather than a copied claim. It keys on the encoded phrase
string from encodeRichText, not on a token array:
{n} via JSX "Based on 0 {m0o}reviews{m0c}" (new key per value)
%n% placeholder "Based on {n} {m0o}reviews{m0c}" (stable across values)
Same outcome as Translate, different mechanism.
JSDoc is worth more than usual on these two: it ships inside dist/ and
is what IDE hover renders, so for a consumer who never opens the README
it is the documentation.
Prompted by langsys-js-svelte, who found the same omission in
Phrase.svelte's JSDoc after fixing their README.
b46f59a
build: allow releasing when HEAD is already pushed
The script bumped the version by amending HEAD, so it required an
unpushed commit and aborted otherwise. That abort was correct given the
amend -- amending a published commit force-pushes a rewrite and orphans
any tag or attestation pointing at the original SHA -- but it turned an
ordinary habit, pushing work when you finish it, into a dead end. The
only ways out were a junk commit (which the comment there explicitly
warns against) or rewinding the remote. The abort was protecting the
amend; the amend is what needed to be conditional.
The fresh ahead-count now selects a strategy instead of gating the run:
ahead > 0 HEAD is local-only -> amend, force-push (unchanged)
ahead = 0 HEAD is published -> new "chore: release X.Y.Z" commit,
plain push, no force at all
Both guards are untouched and both still run before this decision: the
fetch, then the divergence check, then the count. The count being FRESH
remains load-bearing for the same reason as before -- a stale ref
over-reports and would route a published HEAD onto the amend path, which
the divergence guard cannot catch because behind is legitimately 0.
The bump itself can't be skipped: CI checks out the release tag and runs
npm publish, which reads package.json, so the tagged commit has to carry
the new version already. Tagging an untouched HEAD republishes the
previous version and fails.
Rollback needed no change -- HEAD@{1} is the pre-amend commit on one path
and the pre-commit HEAD on the other -- but its comment said "before
amend" and now says both.
f98a1bb
chore: release 0.6.7
Full Changelog
See the commit history for a complete diff of all changes.
v0.6.6
Release v0.6.6
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.6Changes in this release
1dcdd0c
docs: standardize README shields under the H1
Adopts the agreed cross-SDK shield set. Fixes two defects in the old
block:
- the license badge queried npm/l/all-contributors — the
all-contributors package's license, not ours. It rendered 'MIT'
because that package is also MIT, so it looked correct while
reporting someone else's license. - four of five badges had empty link targets '()' and navigated
nowhere.
Also drops GitHub Release (duplicates npm version), open PRs, and the
decorative PRs-welcome badge; adds build, bundle size, types, and
downloads. Endpoints verified against this repo: ci.yml exists, license
is MIT with a LICENSE file, types field is set.
Not released — README changes only reach npmjs.com on the next publish.
1d825a4
chore: base SDK ^0.6.5 (BCP 47 debug warning)
Debug-mode warning when a locale tag isn't valid BCP 47 — reached from
whatever this package's locale store feeds in, so it applies directly
to useLocaleStore/createLocaleStore input. Behavior, return values, and
production output all unchanged.
Also carries the previously-held README shield standardization (1dcdd0c),
which only reaches npmjs.com's package page on a publish.
[Version bumped to 0.6.6]
Full Changelog
See the commit history for a complete diff of all changes.
v0.6.5
Release v0.6.5
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.5Changes in this release
670d0a9
docs: correct attribute-harvesting claims
Two defects in one inherited line, verified against the published
0.6.4 bundle:
- the attribute list named 4 of the 15 in TRANSLATABLE_ATTRIBUTES,
omitting label, four ARIA strings, and six data-* validation
messages. The ARIA ones matter most — untranslated ARIA is invisible
on the page and only surfaces to screen-reader users. - 'button/input value' over-promised. value is translated on
and input type=submit|button only; every other input type is left
alone so a text field's value is never rewritten.
No behavior change. Flagged by the Vue binding agent, who had the
same inherited line.
[Version bumped to 0.6.5]
Full Changelog
See the commit history for a complete diff of all changes.
v0.6.4
Release v0.6.4
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.4Changes in this release
5c97a1d
fix: base SDK ^0.6.4 (raw ICU source rendered on missing argument)
User-visible, unlike the recent bumps. A missing ICU argument fell
through to the simple {key} interpolator, which can't match an ICU
slot, so the whole construct rendered verbatim to the page. Reachable
with no caller mistake: langsys-ai's ICU promoter can introduce a
select argument the source phrase never had, which the app cannot
supply.
Recovery matches langsys-php so a shared catalog renders one sentence:
missing select -> other branch; missing plural -> other with # as
{count}. null now counts as missing instead of coercing to 0, which
had made a missing value indistinguishable from a genuine zero.
[Version bumped to 0.6.4]
Full Changelog
See the commit history for a complete diff of all changes.
v0.6.3
Release v0.6.3
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.3Changes in this release
d64c81d
fix: base SDK ^0.6.3 ( option double-harvest) Option text was harvested twice, which changed the token list and so the custom_id for any content block containing a select. Inherited fix, no wrapper API change. Documents the consumer-facing consequences, since this README presents select-inside-Translate as a supported pattern: unaffected content doesn't rebase, affected blocks migrate automatically via a three-step id fallback, and PHP-render/JS-hydrate setups may see blocks gain translations as ids converge with langsys-php. [Version bumped to 0.6.3] Full Changelog See the commit history for a complete diff of all changes.
v0.6.2
Release v0.6.2
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.2Changes in this release
6ce4637
fix: base SDK ^0.6.2; correct doc claim
Base 0.6.2 honors PHP's data-notrans alias, matches translate=no
case-insensitively, and trims phrase-marker values. Inherited, no
wrapper API change.
Also corrects a false claim carried since 0.2.0: data-ls-dont-translate
was documented as honored by the base SDK. It never was, in any
published version 0.1.0-0.6.2 — verified against each tarball. No
behavior change; exclusion has always rested on translate='no'. The
attribute stays as a wrapper-level hook and is documented as one.
[Version bumped to 0.6.2]
Full Changelog
See the commit history for a complete diff of all changes.
v0.6.1
Release v0.6.1
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.1Changes in this release
a685ffd
build: stamp CHANGELOG release date in publish.sh
Headings are now written '## X.Y.Z - unreleased' and dated by the
release script immediately before tagging, so the heading agrees with
npm's publish record by construction rather than by remembering to
check. A hand-dated heading records when it was typed, not when it
shipped — that dated 0.4.2/0.4.3 a month early.
Also warns when the version being released has no CHANGELOG section,
and un-stamps on rollback. Logic verified against all three branches
plus the rollback path.
1d596b2
fix: base SDK ^0.6.1 (phrase-marker opt-out handling)
0.6.0 matched data-langsys-phrase on presence alone, so an explicit
='false'/='0' opt-out was skipped by this SDK and left untranslated by
PHP as well. Inherited fix, no wrapper API change.
First release using the 'unreleased' heading — publish.sh stamps the
date.
[Version bumped to 0.6.1]
Full Changelog
See the commit history for a complete diff of all changes.
v0.6.0
Release v0.6.0
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.6.0Changes in this release
7dcba82
docs: backfill missing CHANGELOG entry for 0.2.1
v0.2.1 shipped with no changelog section — the only tag-vs-heading gap
in this repo. Reconstructed from git log v0.2.0..v0.2.1 and marked
retroactive with the reconstruction date, so the record stays honest
rather than implying it was written at release time.
cdc237e
docs: sharpen retroactive 0.2.1 entry with sourced base-SDK details
The base-SDK maintainer supplied per-release summaries, now real
sections in their changelog rather than commit archaeology, so the
specifics can be cited. Also notes that ^0.2.2 admits base 0.2.3,
whose ready()-never-settles fix presented in this wrapper as
/ mounting but never rendering on SSR-seeded pages.
ca284b4
docs: correct four changelog dates against the npm publish record
Applied the same audit the base SDK ran, to this repo: 0.4.2 and 0.4.3
were dated 2026-07-08 but published 2026-08-08; 0.2.0 was off by a day
and 0.1.0 by nearly two weeks. All nine entries now match
'npm view langsys-js-react time'.
Notably 0.4.2/0.4.3 were written at release time, not reconstructed —
the session clock disagreed with the publish record by a month.
e2dc403
feat: base SDK ^0.6.0 (md5 custom_id fix + PHP phrase-marker interop)
Both fixes are inherited — no wrapper API change. Also ties 's
emitted marker to the base SDK's exported PHRASE_MARKER_ATTR rather
than a hardcoded string; rendered output is byte-identical, verified by
the existing component test.
[Version bumped to 0.6.0]
Full Changelog
See the commit history for a complete diff of all changes.
v0.5.0
Release v0.5.0
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.5.0Changes in this release
3acd6c0
fix(types): narrow PhraseProps.params to ParamPrimitive
Matches TranslateProps.params and t(). The loose Record<string, unknown>
allowed values interpolation can only render as [object Object]
(objects, arrays, functions).
Compatible with both base 0.4.x and the upcoming 0.5.0, which narrows
PhraseOptions.params the same way: verified typecheck/test/build clean
against the installed 0.4.3, so this lands ahead of the bump rather
than racing it. Runtime behavior unchanged.
c4d9209
chore: base SDK ^0.5.0; document Phrase params narrowing as breaking
Pure floor bump — the narrowing itself landed in 3acd6c0 ahead of the
release, so no code is coupled to this. Changelog states the break in
consumer terms: passing an object/array as a param value stops
compiling, which surfaces code that was already rendering
[object Object].
[Version bumped to 0.5.0]
Full Changelog
See the commit history for a complete diff of all changes.
v0.4.3
Release v0.4.3
This release includes all changes since the previous version.
Installation
npm install langsys-js-react@0.4.3Changes in this release
8ed1d37
chore: base SDK ^0.4.3 (framework-neutral diagnostic wording)
0.4.3 rewords the debug diagnostic so it no longer hardcodes
Svelte/JSX and the {key} spelling, which misdiagnosed Vue's
{{ key }}. Behavior unchanged. The README quote elides that
sentence, so no doc change needed.
[Version bumped to 0.4.3]
Full Changelog
See the commit history for a complete diff of all changes.