Recording a scope boundary for the native-binding removal campaign, decided by the owner on 2026-09-19, so that nobody spends a probe or a removal attempt on it later.
Native-addon packages are out of scope. The campaign's premise is "delete the hand-written Rust reimplementation, compile the real npm package instead". That premise does not hold for packages whose real implementation is a C++/N-API addon rather than JavaScript: compiling them from source means supporting N-API, which is a different project from anything this campaign does.
The binding entries affected:
argon2bcryptbetter-sqlite3sharp@parcel/watcher — plus its nine platform packages (-darwin-arm64, -darwin-x64, -linux-arm64-glibc, -linux-arm64-musl, -linux-x64-glibc, -linux-x64-musl, -win32-arm64, -win32-x64)
That is 13 of the 43 npm-package binding entries currently registered in crates/perry/well_known_bindings.toml.
A related case worth knowing about, because the version determines the answer: typescript. Perry's binding targets 5.8.2, which is the JavaScript implementation and therefore a legitimate removal candidate. But TypeScript 7.x is the Go-based native compiler — optionalDependencies on platform binaries (@typescript/typescript-linux-x64 and siblings), a vendor/ directory, and a bin/tsc shim over roughly 1 MB of JS API surface. So the same package name is in scope at one major and out of scope at the next. Anyone probing it should use the version the binding's [bindings.typescript.upstream] block pins, not npm install typescript latest.
What this does not settle. Whether these bindings should stay indefinitely, be replaced by N-API support, or be dropped with the functionality removed, is a separate decision that nobody has made. This issue records only that they are not part of the current "compile the real package" campaign, so their continued presence is not an outstanding task under it.
Every other binding remains in scope: 7 have open removal PRs (#10677, #10680, #10691, #10693, #10704, #10708, #10712), redis is blocked on #10660, and the rest are being probed for compilability.
Recording a scope boundary for the native-binding removal campaign, decided by the owner on 2026-09-19, so that nobody spends a probe or a removal attempt on it later.
Native-addon packages are out of scope. The campaign's premise is "delete the hand-written Rust reimplementation, compile the real npm package instead". That premise does not hold for packages whose real implementation is a C++/N-API addon rather than JavaScript: compiling them from source means supporting N-API, which is a different project from anything this campaign does.
The binding entries affected:
argon2bcryptbetter-sqlite3sharp@parcel/watcher— plus its nine platform packages (-darwin-arm64,-darwin-x64,-linux-arm64-glibc,-linux-arm64-musl,-linux-x64-glibc,-linux-x64-musl,-win32-arm64,-win32-x64)That is 13 of the 43 npm-package binding entries currently registered in
crates/perry/well_known_bindings.toml.A related case worth knowing about, because the version determines the answer:
typescript. Perry's binding targets 5.8.2, which is the JavaScript implementation and therefore a legitimate removal candidate. But TypeScript 7.x is the Go-based native compiler —optionalDependencieson platform binaries (@typescript/typescript-linux-x64and siblings), avendor/directory, and abin/tscshim over roughly 1 MB of JS API surface. So the same package name is in scope at one major and out of scope at the next. Anyone probing it should use the version the binding's[bindings.typescript.upstream]block pins, notnpm install typescriptlatest.What this does not settle. Whether these bindings should stay indefinitely, be replaced by N-API support, or be dropped with the functionality removed, is a separate decision that nobody has made. This issue records only that they are not part of the current "compile the real package" campaign, so their continued presence is not an outstanding task under it.
Every other binding remains in scope: 7 have open removal PRs (#10677, #10680, #10691, #10693, #10704, #10708, #10712),
redisis blocked on #10660, and the rest are being probed for compilability.