Avatar for the swc-project user
swc-project
swc
BlogDocsChangelog

Performance History

Latest Results

fix(es/decorators): handle import types in decorator metadata (#11916) **Description:** Fixes a legacy decorator metadata panic when a decorated TypeScript member uses an inline import type such as `import("./Message").Message`. The metadata serializer now treats `TsImportType` as an unresolvable transpile-only type and emits `Object`, matching TypeScript's runtime metadata behavior. The catch-all serializer path also falls back to `Object` instead of panicking on well-formed TS type nodes, and bigint literal metadata now follows the existing `BigInt` constructor fallback. Added legacy metadata fixtures for import types on properties, methods, constructors, parenthesized/generic/union/intersection forms, and bigint literal metadata. Validation: - `git submodule update --init --recursive` - `UPDATE=1 cargo test -p swc_ecma_transforms --all-features --test decorators legacy_metadata_tests__fixture__legacy_metadata__issues__11915 -- --include-ignored` - `cargo test -p swc_ecma_transforms --all-features --test decorators legacy_metadata_tests__fixture__legacy_metadata__issues__11915 -- --include-ignored` - `cargo test -p swc_ecma_transforms --all-features --test decorators legacy_metadata_tests -- --include-ignored` - `cargo test -p swc_ecma_transforms_proposal` - `cargo test -p swc_ecma_transforms` - `cargo fmt --all` - `cargo clippy --all --all-targets -- -D warnings` Note: `cargo test -p swc_ecma_transforms --all-features` was also attempted locally, but exec tests requiring `mocha` could not run because `mocha` is not installed on PATH in this environment. **Related issue:** Closes #11915
main
12 hours ago
chore: add changeset for decorator metadata fix
kdy1/fix-11915-decorator-metadata
13 hours ago
fix(es): handle import types in decorator metadata
kdy1/fix-11915-decorator-metadata
13 hours ago
fix(es/renamer): Avoid duplicate mangled names across eval scope boundaries (#11913) **Description:** `mangle` produces colliding identifiers when `eval` is present in a function, which breaks the program at runtime. When `eval` exists, the renamer can't mangle the whole program at once: it builds the top-level map first, renames eval-free nested functions per-unit, and applies the top-level map last. Each `get_map` call built its mangle map with a fresh `ReverseMap`, so a per-unit map for a nested function could reuse a Base54 name already assigned by the top-level map. This becomes observable together with the compressor's scalar replacement, which rewrites `var x = { p: [] }; x.p.push(...)` into a synthetic `var x_p = []; x_p.push(...)`. The synthetic binding isn't covered by the `eval` bypass, so it lands in the top-level map and collides with the names chosen independently for an eval-free callback. I considered fixing this in the compressor (skipping scalar replacement when `eval` is in scope), but that trades away an optimization and has a wider regression surface. Instead the fix is in the renamer: the rename pass records the names assigned by the top-level map and feeds them as reserved symbols to the per-unit maps, so their encoders skip names already in use. The reserved set is only populated on the `eval` path, so non-eval programs are unaffected. Verified with two `exec` (runtime) tests that run compress + mangle together and compare stdout — the base repro and a nested-callback variant. Both fail without the fix (the collided output throws at runtime) and pass with it. **Related issue:** Closes #11294
main
2 days ago
CLI run
by
Avatar for the kdy1 user
kdy1
3 days ago
CLI run
by
Avatar for the kdy1 user
kdy1
3 days ago

Latest Branches

CodSpeed Performance Gauge
0%
fix(es/decorators): handle import types in decorator metadata#11916
13 hours ago
2452aa8
kdy1/fix-11915-decorator-metadata
CodSpeed Performance Gauge
0%
2 days ago
4e9e591
baltasarblanco:fix/11294-mangler-eval-duplicate-idents
CodSpeed Performance Gauge
0%
3 days ago
bfb0212
kdy1/skills
© 2026 CodSpeed Technology
Home Terms Privacy Docs