Release v1.0.2 — eight-locale localization, Open VSX links, CI - #2
Open
ElecTreeFrying wants to merge 11 commits into
Open
Release v1.0.2 — eight-locale localization, Open VSX links, CI#2ElecTreeFrying wants to merge 11 commits into
ElecTreeFrying wants to merge 11 commits into
Conversation
CI proved `npm run compile` passed, which is not what a release depends on. Two gaps closed: `.github/scripts/check-nls.js` — a dependency-free gate over the package.nls bundles. VS Code substitutes a manifest string only when the whole value matches %key%, so an unresolved key renders literally in the UI and a placeholder embedded in a longer string never substitutes at all. Neither is visible to tsc, eslint, or vsce. It also rejects keys localized in runtime-matched positions (enum values, defaults, command ids), keys missing from any locale, duplicates that JSON.parse would silently collapse, and a .vscodeignore glob that would stop the bundles shipping. Verified to fire on each of those cases, not just to pass on a clean tree. A `package` job that builds the actual VSIX and inspects the archive: all nine nls bundles present, and no maintainer-only tree (src/, .github/, CLAUDE.md, SPEC.md, and each repo's own) leaked in. This is the gate the publish wave depends on and the one CI never ran. Also: job timeouts, and a node 20/22 build matrix so a toolchain break on a newer runtime surfaces here rather than on a dev machine.
The template's checklist covers what CI cannot: that a manifest string change reached all eight locale files, that no enum value or default was localized, that README and CHANGELOG links are absolute (both ship inside the VSIX, where relative paths do not resolve), and that the version was not hand-bumped. CODEOWNERS makes every pull request, including Dependabot's, request a review rather than sit unnoticed. It uses the ElecTreeFrying account handle, which is unchanged — only the publisher's display name is WinterNova5.
The release localizes the extension's name and description into eight display languages, and the SPEC documents it — but the README, which IS the Marketplace and Open VSX listing, said nothing. Anyone browsing the listing had no way to know the extension speaks their language. Added as a Compatibility bullet, matching how the section already states the engine floor, registries, and hosts. It notes that snippet prefixes and bodies stay English on purpose: they are typed identifiers, not display text. The changelog entry's Compatibility sentence now mentions it too.
`vsce` and `@vscode/vsce` are two different npm packages. The unscoped one is deprecated and frozen at 2.15.0, and that version rejects any manifest with `main` but no `activationEvents` — which VS Code has auto-generated from `contributes.commands` since 1.74. Nothing declared @vscode/vsce, so `npx vsce` resolved to the 2023 binary from an npx cache and failed with an error that reads like a manifest bug rather than a stale tool. Declaring it makes the correct version the only reachable one. It was already present in this repo's lockfile as an undeclared transitive dev dependency, which meant any unrelated upgrade could have removed it silently. CI's packaging step now invokes ./node_modules/.bin/vsce by explicit path rather than `npx vsce` or `npm exec -- vsce`. Both of those fall back to the registry when the binary is absent, which is exactly how the deprecated package gets pulled in; the explicit path can only resolve to the locked version, so CI and a local publish run are guaranteed to use the same tool. Dev-only. Verified across all four repos: zero production dependencies changed, esbuild and typescript unmoved, and every shipped bundle byte-identical before and after — auto-import 23ac46b3…, drag-import eabd651b…, insert-random-text bfa4e191…. The large lockfile diffs are npm restructuring the dev tree.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release branch for v1.0.2. Merges into
main, after whichR3cuts the version commit, tag, and the three publish targets.User-facing
displayNameanddescriptionbecome%key%placeholders resolved frompackage.nls.json(English base + per-key fallback) pluszh-cn,es,fr,pt-br,ru,de,ja,tr. All nine files ship in the VSIX.Maintainer-facing
tools/validate.js;tools/is gitignored and absent from a clone, so content fidelity stays a local gate..remember/ignore rules.Not in this branch
No snippet changes.
snippets/**is byte-identical to v1.0.2's predecessor, and the generator was not run.