Bumping napi-rs to v3?

[IronBlood]

Hi all,

I’m working on bumping the napi-rs dependency from v2 to v3. Before I push this further, I’d like to check whether this upgrade is actually worth it for lightningcss.

Why I’m considering it

• Keep it closer to the upstream napi-rs ecosystem and reduce long-term maintenance cost.
• Potentially expand platform support (e.g. x86_64-pc-windows-gnu / MSYS2).

What I'm not sure about

I’m still getting up to speed with lightningcss, napi-rs, and Rust, so I’d appreciate context/feedback on:

• Whether this upgrade has been discussed before (or intentionally postponed), and if there are prior decisions or context I’m missing.
• Whether there’s any concrete benefit for lightningcss specifically (performance, stability, build/release simplicity), versus churn.

What I've done so far

• Migrated the transform, bundle, and bundleAsync APIs. bundleAsync can accept both synchronous and asynchronous callbacks. The file napi/src/threadsafe_function.rs is removed from the building process.
• I believe I introduced a breaking behavior change around. Previously the tests used res.code.toString(), since TransformResult.code was annotated as Uint8Array. That behavior looks confusing, and after returning an actual Uint8Array, .toString() yields comma-separated byte values (e.g. 65,66,67). The correct usage becomes new TextDecoder().decode(res.code). If downstream users rely on .toString(), this could break them. I’m not sure whether we should preserve the old behavior (e.g. return a string) or treat this as a deliberate correction and document it.
• I only started running the JS tests today. I’m trying to keep test changes minimal. wasm32 and some features aren’t covered yet. I’m currently working through error handling in bundleAsync.

If folks have opinions either way—especially any past discussion, known v2→v3 pitfalls, or guidance on the code return type—I’d really appreciate it.

[IronBlood]

Hi there, happy new year.

I have barely bumped the APIs with napi v3.7.0 and the latest stable toolchain, tested on x86_64 Linux GNU, with 72/72 passed. The only changes to the test files are just using new TextDecoder().decode(). Wasm hasn't been covered yet.

Here's my working branch.

My next step:

1. Change typed array to buffer, so that it won't affect downstream users.
2. Have wasm build and run the tests.
3. Run tests on more operating systems.
4. Fix index.d.ts