…104)

The previous commit's defensive load fixed `npm install` (optionalDependencies
move) and the require-fallback in the codegen. CI now confirms install passes.

But the smoke job still fails at the next step — `xvfb-run npm test`:

  Activating extension 'hyperpolymath.affinescript' failed:
  WebAssembly.instantiate(): Import #1 "Vscode": module is not an object
  or function.

The compiled extension.cjs's wasm module imports 18 `Vscode` functions and
3 `VscodeLanguageClient` functions from the adapter. With the adapter
missing, extraImports returns {} and the wasm can't instantiate.

Inlining a full stub for all 21 imports would require enumerating the
compiler's emitted import list in the codegen (non-trivial — the import
set depends on which stdlib bindings the .affine source uses) and would
hide real binding-API drift. Not worth doing for a baseline-rot fix.

Cleanest reversible unblock: `continue-on-error: true` on the job, with
an inline comment pinned to #104 documenting the exact condition for
removal (npm org create + NPM_TOKEN + affine-vscode-v0.1.0 tag push).
Job still runs and reports red on the PR page so loss-of-coverage is
visible, but it stops blocking merges.

When #104 lands → delete the `continue-on-error: true` line. Single grep
target.

Refs #104.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…104)

The previous commit's defensive load fixed `npm install` (optionalDependencies
move) and the require-fallback in the codegen. CI now confirms install passes.

But the smoke job still fails at the next step — `xvfb-run npm test`:

  Activating extension 'hyperpolymath.affinescript' failed:
  WebAssembly.instantiate(): Import #1 "Vscode": module is not an object
  or function.

The compiled extension.cjs's wasm module imports 18 `Vscode` functions and
3 `VscodeLanguageClient` functions from the adapter. With the adapter
missing, extraImports returns {} and the wasm can't instantiate.

Inlining a full stub for all 21 imports would require enumerating the
compiler's emitted import list in the codegen (non-trivial — the import
set depends on which stdlib bindings the .affine source uses) and would
hide real binding-API drift. Not worth doing for a baseline-rot fix.

Cleanest reversible unblock: `continue-on-error: true` on the job, with
an inline comment pinned to #104 documenting the exact condition for
removal (npm org create + NPM_TOKEN + affine-vscode-v0.1.0 tag push).
Job still runs and reports red on the PR page so loss-of-coverage is
visible, but it stops blocking merges.

When #104 lands → delete the `continue-on-error: true` line. Single grep
target.

Refs #104.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…e fix for #139/#104)

The `--vscode-extension` codegen previously emitted a runtime require()
of `@hyperpolymath/affine-vscode` to source the WASM's `Vscode` and
`VscodeLanguageClient` import modules. That package isn't published to
npm yet (gated on owner action in #104), so the require failed,
extraImports() returned {}, and the WASM activation failed:

  WebAssembly.instantiate(): Import #1 "Vscode":
    module is not an object or function

The previous CI workaround (PR #377) added a `file:` install of the
in-tree adapter as a smoke-test-step bridge — useful but not a root
fix.

This commit eliminates the runtime npm dependency entirely:

1. New dune rule generates `lib/affine_vscode_adapter_source.ml` from
   `packages/affine-vscode/mod.js` at build time, exposing the source
   as an OCaml string constant.

2. `vscode_extension_wiring` in `lib/codegen_node.ml` now inlines the
   adapter source into the generated `.cjs` as a CJS-style closure:

     try { _makeVscodeBindings = require("@hyperpolymath/affine-vscode"); }
     catch (_e) { /* fall through to embedded adapter */ }
     if (typeof _makeVscodeBindings !== "function") {
       const _adapterModule = { exports: null };
       (function (module, exports) {
         /* …embedded packages/affine-vscode/mod.js source… */
       })(_adapterModule, _adapterModule.exports);
       _makeVscodeBindings = _adapterModule.exports;
     }

   The require() is still attempted first so an upgraded adapter
   installed via npm can override the embedded copy — but it's no
   longer load-bearing.

3. Regenerated `editors/vscode/out/extension.cjs` with the new codegen
   (618 lines, up from 121 — the delta is the inlined adapter source).

4. Dropped `optionalDependencies` for `@hyperpolymath/affine-vscode`
   from `editors/vscode/package.json` — the extension no longer needs
   it at install time. The package keeps its in-tree home at
   `packages/affine-vscode/` as the source of truth for JSR/npm
   publishing and for `--vscode-extension` codegen consumption.

5. Dropped `continue-on-error: true` from the vscode-smoke job in
   `.github/workflows/ci.yml`. The job is now expected to be reliable;
   a real regression should turn it red and gate.

Verified locally: the regenerated `extension.cjs` loads cleanly under
plain Node (`require()` works, `extraImports` is a function), and the
existing `tools/run_codegen_wasm_tests.sh` suite still passes.

Refs #139 (smoke harness), #104 (pending npm publish — no longer a
runtime blocker), gitbot-fleet#148.

Closes the "fundamental root cause" path opened in PR #377.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…e fix for #139/#104) (#380)

## Summary

The \`--vscode-extension\` codegen previously emitted a runtime
\`require()\` of \`@hyperpolymath/affine-vscode\` to source the WASM's
\`Vscode\` and \`VscodeLanguageClient\` import modules. That package
isn't published to npm yet (gated on owner action in #104), so the
require failed, \`extraImports()\` returned \`{}\`, and WASM activation
failed every CI run with:

\`\`\`
WebAssembly.instantiate(): Import #1 \"Vscode\":
  module is not an object or function
\`\`\`

The previous CI workaround in PR #377 added a \`file:\` install of the
in-tree adapter as a smoke-test-step bridge — useful, but a workaround.
This PR is the **fundamental fix**: it eliminates the runtime npm
dependency entirely by embedding the adapter source at codegen time.

## What this changes

### 1. \`lib/dune\` — adapter source as compile-time string constant

New \`(rule …)\` generates \`lib/affine_vscode_adapter_source.ml\` from
\`packages/affine-vscode/mod.js\` at build time, exposing the JS source
as an OCaml string:

\`\`\`ocaml
(* AUTO-GENERATED from packages/affine-vscode/mod.js. Do not edit. *)
let source = {affine_vscode|/* …mod.js content… */|affine_vscode}
\`\`\`

### 2. \`lib/codegen_node.ml\` — inline at codegen time

\`vscode_extension_wiring\` now emits a CJS-style closure that wraps the
embedded adapter source. The runtime \`require()\` is still attempted
first so an installed package can override the embedded copy — but it's
no longer load-bearing:

\`\`\`js
try { _makeVscodeBindings = require(\"@hyperpolymath/affine-vscode\"); }
catch (_e) { /* fall through to embedded adapter */ }
if (typeof _makeVscodeBindings !== \"function\") {
  const _adapterModule = { exports: null };
  (function (module, exports) {
    /* …embedded packages/affine-vscode/mod.js source… */
  })(_adapterModule, _adapterModule.exports);
  _makeVscodeBindings = _adapterModule.exports;
}
\`\`\`

### 3. Regenerated \`editors/vscode/out/extension.cjs\`

618 lines, up from 121 — the delta is the inlined adapter source.

### 4. \`editors/vscode/package.json\` — drop \`optionalDependencies\`

The \`@hyperpolymath/affine-vscode\` optional-dep is no longer needed at
install time. The package keeps its in-tree home at
\`packages/affine-vscode/\` as the source of truth for JSR/npm
publishing and for \`--vscode-extension\` codegen consumption.

### 5. \`.github/workflows/ci.yml\` — drop \`continue-on-error: true\`

The vscode-smoke job is now expected to be reliable. A real regression
should turn it red and gate.

## Why this is the right fix

Q: \"Can the VS Code extension use Deno instead of npm?\"

A: No — the VS Code extension host is Electron-embedded Node. The host
loads extensions via Node's \`require()\` and the \`.vsix\` package
format expects CJS. CLAUDE.md \"Runtime Exemptions\" already documents
this as a forced carve-out.

But this PR **reduces** npm exposure by eliminating the runtime
dependency on \`@hyperpolymath/affine-vscode\` (one less npm package
needed at smoke time). The only remaining npm carve-outs at smoke time
are \`@vscode/test-electron\` (smoke runner; no alternative exists) and
\`vscode-languageclient\` (LSP client; npm-published).

## Verification

Local:
- Full build: \`opam exec -- dune build\` ✓
- Codegen WASM tests: \`opam exec -- ./tools/run_codegen_wasm_tests.sh\`
✓ (all pass)
- Regenerated .cjs loads under plain Node:
\`require('out/extension.cjs')\` exports \`activate\`, \`deactivate\`,
\`extraImports\` (function) ✓

CI:
- [ ] \`vscode-smoke\` green on this PR (the real test — was relying on
file:-install bridge from #377; now self-contained)
- [ ] Build / lint / format checks all pass

## Coordination with #377

#377 adds a \`file:\` install bridge in CI that solves the same symptom
at the workflow level. If #377 lands first, this PR's removal of
\`continue-on-error\` and the embedded adapter make the file: install
redundant (it's harmless — the require() inside extension.cjs picks up
the npm-installed version first and uses it; falls back to embedded only
when not installed). If this PR lands first, #377 becomes a no-op
pre-existing-step removal and can be closed.

Refs #139 (smoke harness), #104 (pending npm publish — no longer a
runtime blocker), gitbot-fleet#148.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>