chore(cli): throw error if wasi file not found when NAPI_RS_FORCE_WASI=error#2919
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
aa8b785 to
ee2f5f5
Compare
ee2f5f5 to
bb4eee5
Compare
|
cursor review |
There was a problem hiding this comment.
Pull Request Overview
This PR implements a new error handling mechanism for WASI file loading when NAPI_RS_FORCE_WASI=error is set. The change addresses issue #2918 by adding explicit error throwing when WASI binding files are not found in error mode.
- Adds error throwing when
NAPI_RS_FORCE_WASI=errorand WASI binding files cannot be loaded - Refactors WASI binding loading logic to track binding state and errors more precisely
- Updates package dependencies across multiple workspace packages
Reviewed Changes
Copilot reviewed 15 out of 18 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| cli/src/api/templates/js-binding.ts | Implements the core WASI error handling logic with improved error tracking |
| examples/napi/index.cjs | Generated binding file reflecting the new error handling template |
| examples/napi/index.d.cts | Adds ReadableStream type import for better TypeScript support |
| examples/napi/tests/values.spec.ts | Updates comment for ReadableStream polyfill type conflict |
| examples/napi/browser/values.spec.ts | Adds generic type parameter to Promise.withResolvers |
| examples/napi/tsconfig.json | Updates types configuration from bun-types to node |
| package.json, */package.json | Updates various package dependencies to newer versions |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
The generated native.js template treated process.env.NAPI_RS_FORCE_WASI as a plain truthy-string check. In JavaScript any non-empty string is truthy, including 'false' and '0', so setting NAPI_RS_FORCE_WASI=false (intending to opt out of forced WASI) inadvertently triggered the WASI fallback — the same path that tries to load <pkg>.wasi.cjs and fails with ENOENT for packages that don't ship a WASI binding. Reported by lancedb/lancedb#3267, where downstream users hit: ENOENT: no such file or directory, open '.../@lancedb/lancedb/dist/lancedb.wasi.cjs' This patch extracts a single `forceWasi` boolean at the top of the generated script (equal to 'true' or 'error') and uses it consistently at the four call sites that previously did a truthy-string check. The existing `=== 'error'` branch at the bottom is preserved unchanged — it already did the right thing. This is a template change, so the fix is picked up the next time a downstream package runs `napi build`. No behavior change for existing users who had NAPI_RS_FORCE_WASI unset or set to 'true'/'error'. Related: PR napi-rs#2919 added the 'error' tri-state; this patch completes the tri-state handling by making the other two values ('true' and everything-else) behave as documented. Signed-off-by: Mukunda Katta <[email protected]>
The generated native.js template treated process.env.NAPI_RS_FORCE_WASI as a plain truthy-string check. In JavaScript any non-empty string is truthy, including 'false' and '0', so setting NAPI_RS_FORCE_WASI=false (intending to opt out of forced WASI) inadvertently triggered the WASI fallback — the same path that tries to load <pkg>.wasi.cjs and fails with ENOENT for packages that don't ship a WASI binding. Reported by lancedb/lancedb#3267, where downstream users hit: ENOENT: no such file or directory, open '.../@lancedb/lancedb/dist/lancedb.wasi.cjs' This patch extracts a single `forceWasi` boolean at the top of the generated script (equal to 'true' or 'error') and uses it consistently at the four call sites that previously did a truthy-string check. The existing `=== 'error'` branch at the bottom is preserved unchanged — it already did the right thing. This is a template change, so the fix is picked up the next time a downstream package runs `napi build`. No behavior change for existing users who had NAPI_RS_FORCE_WASI unset or set to 'true'/'error'. Related: PR #2919 added the 'error' tri-state; this patch completes the tri-state handling by making the other two values ('true' and everything-else) behave as documented. Signed-off-by: Mukunda Katta <[email protected]>

wasibinding is not found withNAPI_RS_FORCE_WASI=errororNAPI_RS_FORCE_WASI=1#2918