Keep inline Wasm staging package scoped

[hyfdev]

Summary

• restore the inline Wasm staging identity to @taffyjs/binding-wasm32-wasip1
• clarify that its require.resolve appears only in napi-rs template source and is removed when the Wasm binary is inlined
• verify the final package graph contains no package resolution, binding package name, binding dependency, or standalone .wasm file
• record inline Wasm as the explicit scoped exception to the normal package-scope boundary

Why

The Wasm build is special: it uses napi-rs's scoped staging identity while assembling @taffyjs/wasm, but the staging package is not a runtime or published dependency. The previous change incorrectly treated the staging identity itself as an ordinary unpublished package.

Impact

The final @taffyjs/wasm package remains fully inline. Consumer imports and runtime behavior do not change, and no binding package is installed or resolved at runtime.

Validation

• vp fmt --check
• vp lint --deny-warnings
• vp run check
• vp run check:wasm
• verified .napi-build contains the scoped napi-rs template fallback while final dist contains no require.resolve, binding package name, or .wasm file
• package inspection checks every manifest dependency map, including dependencies and all *Dependencies, for accidental binding dependencies
• independent adversarial review findings were addressed and the final regression checks passed

[Copilot]

Pull request overview

Restores the inline Wasm staging identity to the scoped napi-rs name while tightening the “fully inlined” guarantee (no runtime require.resolve, no binding package references/deps, no standalone .wasm in the published tarball) and documenting the scoped exception in PCR records.

Changes:

• Update the inline Wasm loader template replacement to match napi-rs’s scoped staging fallback and adjust forbidden-token checks accordingly.
• Strengthen package-contents verification to ensure dist contains no require.resolve and no binding-wasm references, and broaden dependency scanning across all *Dependencies maps.
• Record the scoped Wasm staging exception in .agents/docs/ decision ledgers and package design documentation.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tools/taffy-wasm/generate-inline-wasm-runtime-files.ts	Updates exact-match replacement of napi-rs fallback block and validates the generated inline Node loader output.
tests/taffyjs-wasm/tests/package-contents.ts	Expands package inspection assertions to catch resolver calls, binding strings, and binding dependencies.
packages/taffyjs-wasm/package.json	Aligns napi.packageName with the scoped binding identity.
.agents/docs/tooling-decisions.md	Updates scope-boundary ruling to include the explicit inline Wasm staging scoped exception.
.agents/docs/taffyjs-wasm-package.md	Clarifies how the scoped staging fallback is removed during inlining and updates the verification contract.

Suppressed comments (1)

tests/taffyjs-wasm/tests/package-contents.ts:90

• dependencyNames treats any key ending with Dependencies as a dependency map, but some of these fields can legally be arrays (notably bundledDependencies/bundleDependencies). Using Object.keys() on an array yields numeric indices, which can hide an accidental binding-wasm entry. Handle arrays by returning their string values so the check can’t miss bundled dependency names.

const dependencyNames = Object.entries(manifest.default).flatMap(([key, dependencies]) => {
  const isDependencyMap = key === "dependencies" || key.endsWith("Dependencies");
  if (!isDependencyMap || typeof dependencies !== "object" || dependencies === null) {
    return [];
  }
  return Object.keys(dependencies);
});

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.