Repository navigation
Scope boundary: native-addon packages (argon2, bcrypt, better-sqlite3, sharp, @parcel/watcher) are out of the binding-removal campaign #10755
Description
Activity
A second structural exclusion, distinct from the native-addon one above:
ioredis's binding key is shared load-bearing infrastructure, not merely a package name.Found while probing it for removal. The binding key and dispatch string
"ioredis"is whatiovalkeyandredisresolve through — confirmed byext_registry.rs's own comment and by bare-Redisresolution across eight HIR files. Removing theioredisbinding would break both siblings, which are staying (redisis blocked on #10660,iovalkeyon the cosmetic #10760).So
iorediscannot be removed as an independent unit. Either the shared resolution machinery gets a name of its own first — the waytypescriptwas renamed tobun-transpilerwhen its crate turned out to back Bun's API — or all three Redis clients get removed together once their individual blockers are cleared.This is the third case in this campaign where a binding key turned out to mean more than "this npm package":
typescript— the crate also backed Bun'sTranspiler/buildAPI via itsbun.rssubmodule; resolved by renaming the key tobun-transpilerand reclassifying the crateexternalize→keep.node-cron— sharedperry-ext-cronwithcron; resolved as a metadata-only removal leaving the crate for its other user.ioredis— shared resolution infrastructure withiovalkeyandredis; unresolved, and the reason ioredis stays.
Worth stating as a general caution for anyone continuing this work: a
[bindings.X]entry is not reliably a statement that X is an npm package Perry reimplements. Some are, some are load-bearing names that other things resolve through. Grep for the key's use inext_registry.rsand the HIR resolution paths before assuming a removal is self-contained — all three cases above would have broken something if handled mechanically, and two of them were only caught because the removal agent stopped to check rather than deleting on pattern.
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.