@napi-rs/cli 3.8.2 → 3.8.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -4
- package/dist/cli.js +527 -25
- package/dist/index.cjs +527 -25
- package/dist/index.d.cts +1 -1
- package/dist/index.d.ts +1 -1
- package/dist/index.js +527 -25
- package/docs/wasi.md +14 -0
- package/package.json +2 -2
- package/src/api/__tests__/__snapshots__/templates.spec.ts.md +795 -18
- package/src/api/__tests__/__snapshots__/templates.spec.ts.snap +0 -0
- package/src/api/__tests__/pre-publish.spec.ts +36 -1
- package/src/api/__tests__/templates.spec.ts +133 -1
- package/src/api/pre-publish.ts +18 -12
- package/src/api/templates/load-wasi-template.ts +546 -17
package/docs/wasi.md
CHANGED
|
@@ -181,3 +181,17 @@ The deferred `./workerd` loader defaults to 1,024 pages (64 MiB), leaving
|
|
|
181
181
|
headroom under workerd's 128 MiB isolate limit. An explicit
|
|
182
182
|
`napi.wasm.initialMemory` value applies to every loader, so keep it within the
|
|
183
183
|
target isolate's limit after measuring the addon's actual requirements.
|
|
184
|
+
|
|
185
|
+
Threaded browser loaders always pre-create a pool of wasi-threads workers at
|
|
186
|
+
module initialization, sized as `asyncWorkPoolSize + hardwareConcurrency`
|
|
187
|
+
(logical cores, floored at 2, with a fallback for privacy-fuzzed values),
|
|
188
|
+
and therefore always initialize asynchronously. The `asyncWorkPoolSize`
|
|
189
|
+
reservation is included because emnapi's async-work pool draws its workers
|
|
190
|
+
from the same reuse pool; without it, async work could starve the pool
|
|
191
|
+
before addon thread spawns. This is what allows addon Rust code to spawn
|
|
192
|
+
threads from inside a blocking call: a browser cannot start a worker until
|
|
193
|
+
the blocking thread returns to its event loop, so a thread spawned mid-call
|
|
194
|
+
would never boot and the caller would deadlock waiting for it. With a
|
|
195
|
+
pre-created pool, spawning is only a message to an already-running worker,
|
|
196
|
+
and if the pool is exhausted the fallback allocates a fresh worker that
|
|
197
|
+
boots once the spawning parent returns to its event loop.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@napi-rs/cli",
|
|
3
|
-
"version": "3.8.
|
|
3
|
+
"version": "3.8.4",
|
|
4
4
|
"description": "Cli tools for napi-rs",
|
|
5
5
|
"author": "LongYinan <lynweklm@gmail.com>",
|
|
6
6
|
"homepage": "https://napi.rs/",
|
|
@@ -86,7 +86,7 @@
|
|
|
86
86
|
"ava": "^8.0.1",
|
|
87
87
|
"empathic": "^2.0.1",
|
|
88
88
|
"env-paths": "^4.0.0",
|
|
89
|
-
"oxc-parser": "^0.
|
|
89
|
+
"oxc-parser": "^0.143.0",
|
|
90
90
|
"prettier": "^3.8.3",
|
|
91
91
|
"tsdown": "^0.22.2",
|
|
92
92
|
"tslib": "^2.8.1"
|