Publish @hyperpolymath/affine-vscode to npm (eliminate vendoring)

[hyperpolymath]

Problem

packages/affine-vscode/mod.js is the JS-side adapter for stdlib/Vscode.affine + stdlib/VscodeLanguageClient.affine. It maps each extern fn to a real vscode / vscode-languageclient/node call and maintains the handle table.

Today the package has no package.json — only mod.js, README.adoc, and deno.json. Consumers outside this repo (currently hyperpolymath/my-lang and hyperpolymath/standards rsr-certifier; soon every other AffineScript-authored VS Code extension) vendor the adapter by copying mod.js into src/affine-vscode-adapter.cjs in their own repo.

Vendoring works but has clear drawbacks:

• Drift risk. Every change to mod.js here requires manual re-sync in every consumer. The bindings PR (feat(vscode-bindings): expand surface for rsr-certifier port (#64) #102) added ~20 new functions; each consumer downstream had to remember to copy them across.
• Update protocol is implicit. There's no machine-readable version to pin, no changelog the consumer can diff against, no tooling to surface "your vendored copy is N commits behind".
• Discoverability. New extension authors find the adapter only by reading existing extensions' source.

Proposed plan

Publish @hyperpolymath/affine-vscode to npm so consumers can npm install @hyperpolymath/affine-vscode and require() the adapter directly. The vendoring step in each extension's src/index.cjs collapses to:

const shim = require("../out/extension.cjs");
const makeVscodeBindings = require("@hyperpolymath/affine-vscode");

shim.extraImports = () => makeVscodeBindings(
    require("vscode"),
    require("vscode-languageclient/node"),
    shim,
);

exports.activate = shim.activate;
exports.deactivate = shim.deactivate;

Steps

1. Add packages/affine-vscode/package.json with name: "@hyperpolymath/affine-vscode", main: "./mod.js", an MIT or PMPL license entry matching the repo, peerDependencies: { vscode: "*", "vscode-languageclient": "^9.0.0" }, and a repository.directory field pointing at this subdirectory.
2. Pick a version (0.1.0 is fine for the first published cut).
3. Confirm the publishing account / token. The hyperpolymath org doesn't currently have an npm presence — decide whether to publish under that scope (needs the npm org creating) or under a personal scope.
4. npm publish --access public from packages/affine-vscode/. Add the publish step to a GitHub Actions workflow guarded on a tag pattern so subsequent releases are tag-driven.
5. Update hyperpolymath/my-lang's vscode-extension and hyperpolymath/standards's rsr-certifier to depend on @hyperpolymath/affine-vscode instead of vendoring; remove their local src/affine-vscode-adapter.cjs files.
6. Document the consumer pattern in packages/affine-vscode/README.adoc (the existing Usage section already gets close — just needs the vendoring escape hatch removed and the npm-install path made primary).

Acceptance criteria

• @hyperpolymath/affine-vscode is resolvable via npm view.
• CI publishes new versions automatically on tag push (no manual npm publish after the first one).
• my-lang vscode-extension and standards rsr-certifier depend on the published package; their local affine-vscode-adapter.cjs files are removed.
• packages/affine-vscode/README.adoc documents the npm-install consumer pattern as primary.

Out of scope

• Cutting a major version. 0.x is fine while the binding surface is still growing organically.
• Replacing the current module.exports = function (...) factory shape with ESM exports. CJS is what the vscode extension host loads.

Related

• Pilot port: hyperpolymath/my-lang#11
• External port: hyperpolymath/standards#46
• Adapter origin: Add Node-target backend + vscode-API bindings to enable .affine VS Code extensions #35, feat(vscode-bindings): expand surface for rsr-certifier port (#64) #102