Update @emnapi/runtime 1.8.1 → 1.9.2 (minor)#19971
Conversation
WalkthroughUpdates the 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@crates/node/npm/wasm32-wasi/package.json`:
- Around line 31-32: Update the emnapi core dependency version to match the
runtime: change "@emnapi/core": "^1.8.1" to "@emnapi/core": "^1.9.2" in
package.json so both companion packages use the same ^1.9.2 version (ensure
package.json entry for "@emnapi/core" is updated and run your package manager to
install/lock the new version).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 50481dd1-a3df-4f35-98f4-60ef45a851ad
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
crates/node/npm/wasm32-wasi/package.json
| "@emnapi/core": "^1.8.1", | ||
| "@emnapi/runtime": "^1.8.1", | ||
| "@emnapi/runtime": "^1.9.2", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check available versions and peer dependencies for emnapi packages
echo "=== `@emnapi/runtime` versions ==="
npm view `@emnapi/runtime`@1.9.2 peerDependencies
npm view `@emnapi/runtime`@1.9.2 dependencies | grep -i emnapi || echo "No emnapi dependencies"
echo -e "\n=== `@emnapi/core` latest versions ==="
npm view `@emnapi/core` versions --json | jq -r '.[-5:]'
echo -e "\n=== Check if `@emnapi/core` 1.8.1 is compatible with `@emnapi/runtime` 1.9.2 ==="
npm view `@emnapi/core`@1.8.1 versionRepository: tailwindlabs/tailwindcss
Length of output: 1814
🌐 Web query:
@emnapi/runtime 1.9.2 peer dependencies compatibility
💡 Result:
For @emnapi/runtime v1.9.2, there is no peerDependency declared by the package itself. It depends only on tslib, while peer-dependency compatibility is enforced by downstream packages that require matching @emnapi/core and @emnapi/runtime versions. What’s in @emnapi/runtime@1.9.2 - Package metadata for @emnapi/runtime (including v1.9.2) shows only a dependency on tslib; no peerDependencies are listed. Compatibility expectations (what to align in your project) - If you’re using @napi-rs/wasm-runtime, it declares peerDependencies on: - @emnapi/core: ^1.7.1 - @emnapi/runtime: ^1.7.1 This means @emnapi/runtime@1.9.2 satisfies the peer range. But you should also use a compatible @emnapi/core version (ideally 1.9.2) to avoid version-mismatch checks. - The napi-rs project added/uses version-sync logic to ensure the installed @emnapi package version matches the installed @emnapi/core and @emnapi/runtime versions used during WASM build/package generation, and it notes the move of @emnapi/core and @emnapi/runtime to peerDependencies for wasm-runtime. Practical answer - You can typically pair @emnapi/runtime@1.9.2 with @napi-rs/wasm-runtime (>=1.0.0 and peer range ^1.7.1) as long as your @emnapi/core version is within the expected major line (and preferably the same version, e.g. core@1.9.2). If you tell me which package(s) you’re integrating (e.g., @napi-rs/wasm-runtime, @napi-rs/wasm-tools, emnapi itself, or another wrapper), I can map the exact peer ranges and what versions to install together.
Citations:
- 1: https://registry.npmjs.org/%40emnapi%2Fruntime
- 2: https://registry.npmjs.org/%40napi-rs%2Fwasm-runtime
- 3: https://github.com/napi-rs/napi-rs/pull/3151/changes
- 4: https://registry.npmjs.org/emnapi
🌐 Web query:
@emnapi/core @emnapi/runtime version compatibility issues
💡 Result:
There are no known version compatibility issues between @emnapi/core and @emnapi/runtime. The official emnapi documentation explicitly states: "Each package should match the same version." Both packages follow the same versioning scheme (e.g., latest versions are both 1.10.0 as of April 2026), with synchronized releases from the monorepo at https://github.com/toyobayashi/emnapi. They are designed to be used together at identical versions for Node-API (NAPI) implementations in WebAssembly environments like Emscripten, wasi-sdk, and clang wasm32. Reported issues primarily involve: - Mismatched versions in transitive dependencies (e.g., Next.js/Sharp pulling older @emnapi/runtime@1.5.0). - Runtime errors from version mismatches in prebuilt WASM addons (e.g., linking against emnapi v1.8.1 causing "Cannot read properties of undefined (reading 'whenLoaded')"). To avoid issues: - Install matching versions: npm install @emnapi/core@1.10.0 @emnapi/runtime@1.10.0 - Use npm ls to verify no extraneous/mismatched installations. - Pin exact versions in package.json (avoid ^/~ ranges for these packages). - For Emscripten builds, ensure compatible flags like -pthread for threaded APIs. No peerDependencies are declared between the packages; compatibility is maintained via parallel releases and the monorepo structure.
Citations:
- 1: https://registry.npmjs.org/@emnapi/runtime
- 2: https://www.npmjs.com/package/emnapi
- 3: https://registry.npmjs.org/@emnapi/core
- 4: https://github.com/toyobayashi/emnapi/releases
- 5: https://github.com/toyobayashi/emnapi/
- 6: https://emnapi-docs.vercel.app/guide/
- 7: extraneous emnapi/runtime@1.5.0 in Next.js 15 via Sharp cannot remove vercel/next.js#84450
- 8:
Cannot read properties of undefined (reading 'whenLoaded')error toyobayashi/emnapi#202
🌐 Web query:
emnapi packages changelog release notes 1.8.1 1.9.2
💡 Result:
emnapi (toyobayashi/emnapi) release notes / changelog items for versions 1.8.1 and 1.9.2: 1) v1.8.1 (published 2026-01-04) - The emnapi repo lists tags/releases for v1.8.1, but the captured sources in this research run did not include the v1.8.1 release page’s “What’s Changed” / changelog text. So I can’t reliably quote the specific changes for 1.8.1 from the evidence collected. 2) v1.9.2 (published 2026-04-02) - fix: allow maximum memory 4GB (PR #205).
Citations:
- 1: https://github.com/toyobayashi/emnapi/releases/tag/v1.9.2
- 2: https://security.snyk.io/package/npm/%40emnapi%2Fruntime/versions
- 3: https://github.com/toyobayashi/emnapi/tags
- 4: https://github.com/toyobayashi/emnapi/releases
Align @emnapi/core with @emnapi/runtime version.
The update to @emnapi/runtime@^1.9.2 creates a version mismatch with @emnapi/core@^1.8.1. While technically compatible within peer ranges, official emnapi documentation explicitly recommends matching versions for these companion packages to prevent runtime issues. Update @emnapi/core to ^1.9.2 to align with the runtime version.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@crates/node/npm/wasm32-wasi/package.json` around lines 31 - 32, Update the
emnapi core dependency version to match the runtime: change "@emnapi/core":
"^1.8.1" to "@emnapi/core": "^1.9.2" in package.json so both companion packages
use the same ^1.9.2 version (ensure package.json entry for "@emnapi/core" is
updated and run your package manager to install/lock the new version).
|
Sorry, but the merge failed with:
|
Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.
What changed?
✳️ @emnapi/runtime (1.8.1 → 1.10.0) · Repo
Release Notes
1.10.0
1.9.2
1.9.1
1.9.0
Does any of this look wrong? Please let us know.
Commits
See the full diff on Github. The new version differs by 22 commits:
1.10.0fix: free queue node and set async_pending flag before finalizefix: tsfn use after freeci: llvm 22fix: coalesce tsfn send message (#210)test: fix async_progress_worker test (#209)ci: restructure CI workflows (#208)fix: add missing `from64` wrapfix!: `napi_adjust_external_memory` no longer grow wasm memory (#207)fix: early update wasm memory for views (#206)ci: manual release1.9.2[Backport] fix: allow maximum memory 4GB (#205)1.9.1fix for emscripten 5.0.31.9.0feat: add required config hint in package entryfix: execute tsfn finalizer after queue drains when aborted (nodejs/node#61956)refactor: dispatch async work queue in shared memory (#200)[Backport] fix data race and use-after-free in napi_threadsafe_function (#199)feat!: fix `node_api_create_object_with_properties` name (#193)refactor: use Node-API in comments (#194)Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with
@depfu rebase.All Depfu comment commands