Latest Results
fix(binding/node): Return an error when a file cannot be read instead of panicking (#12379)
## Description
`parse_file_sync` and `transform_file_sync` call `.expect()` on
`load_file`, so a path that cannot be read panics. The release profile
sets `panic = "abort"` ("Abort on panic to remove unwinding code"), so
the `catch_unwind` inside `try_with` never sees it: the panic takes the
whole Node process down.
With the published 1.16.2, on macOS arm64 and node 24.18.0:
```
$ node -e "require('@swc/core').parseFileSync('/definitely/not/here.js', { syntax: 'ecmascript' })"
thread '<unnamed>' panicked at bindings/binding_core_node/src/parse.rs:237:22:
failed to read program file: Os { code: 2, kind: NotFound, message: "No such file or directory" }
$ echo $?
134
```
The async entry points beside them already do the right thing:
`parse_file` and `transform_file` use `.context(...)?` and surface a
rejected promise. This gives the two sync entry points the same
handling.
I ran into it through dependency-cruiser, whose swc parser calls
`parseFileSync`: a module that disappears between the file listing and
the parse, or a broken symlink, ends the whole cruise instead of failing
one module.
## Test
`packages/core/__tests__/parse/api_test.js` gets two cases: `parseFile`
rejects for a path that is not there, and `parseFileSync` throws.
For reviewers: in a debug build both pass with or without the fix,
because unwinding is on there and `catch_unwind` turns the panic into an
error. In a release build, which is what npm ships, the unfixed sync
case aborts the runner.
## Verified locally
macOS arm64, Rust 1.92, node 24.18.0:
- `cargo check -p binding_core_node` is clean.
- `npm run build:dev` in `packages/core`, then `rstest` over that file:
8 passing.
Happy to add a changeset if you want one; the change is in the node
binding only. Latest Branches
-3%
0%
codex/fix-estree-compat-changeset 0%
YuEfSaEDU:fix/pure-destructuring-getters-12373 © 2026 CodSpeed Technology