swc-project/swc · error
ClassMember
Error message
ClassMember::{:?} What it means
In the non-legacy (2022 proposal) decorator transform, SWC builds per-member descriptor info only for constructors, methods, and class properties (ClassMember::Constructor/Method/ClassProp). Any other class member — static blocks, TS index signatures, private properties with decorators, auto-accessors, empty members — falls into the catch-all and panics with `unimplemented!("ClassMember::...")`.
Solutions
- Remove the unsupported member from the decorated class: move static-block init into a static field or the constructor, drop the index signature, or undecorate private fields
- Switch to "legacy": true decorators, which use a different code path that tolerates these members
- Upgrade swc_ecma_transforms_proposal in case the member kind is now handled
Example fix
// before
@decorator
class C {
static { register(C); }
[k: string]: any;
}
// after
@decorator
class C {
static _init = register(C);
} Defensive patterns
Strategy: validation
Validate before calling
// TS-side precheck of source about to be compiled with new decorators
const UNSUPPORTED = /static\s*\{|\[\s*\w+\s*:\s*\w+\s*\]|@\w+\s+#\w+/;
if (decoratorsEnabled && !legacy && UNSUPPORTED.test(src)) {
throw new Error('Decorated class contains static block / index signature / decorated private member');
} Prevention
- Ban static blocks and TS index signatures inside decorated classes when using the 2022 proposal
- Codemod legacy-decorator codebases (strip decorated private fields) before switching legacy:false
- Keep a fixture corpus of decorated classes in CI to catch transform panics on upgrade
When it happens
Trigger: Compiling with jsc.decorators (legacy false) a class that contains a `static { ... }` block, a TS index signature like `[k: string]: any`, a decorated `#privateField`, or another unsupported member while decorators are enabled for that class.
Common situations: Modern TS codebases mixing decorators with static initialization blocks or index signatures; libraries like TypeORM/NestJS entities that add index signatures; enabling the new decorator proposal on code written for legacy decorators.
Related errors
- emitting decorator metadata while using new proposal
- swcify
- Babel doesn't support this right now.
- {decl:?}
- Decl in ExportDecl
AI-assisted analysis of swc-project/swc@5176682b65 (2026-08-17).
Data as JSON: /api/errors/38305c659aa554f8.
Report an issue: GitHub.
Appendix: source
Thrown at crates/swc_ecma_transforms_proposal/src/decorators/mod.rs:557
span: DUMMY_SP,
arg: Some(value),
})],
}),
..Default::default()
}
.into(),
}),
_ => Prop::KeyValue(KeyValueProp {
key: PropName::Ident(quote_ident!("value")),
value: Expr::undefined(DUMMY_SP),
}),
}))))
.collect(),
}
.as_arg(),
)
}
_ => unimplemented!("ClassMember::{:?}", member,),
}
})
.map(Some)
.collect();
make_decorate_call(
class.decorators,
iter::once({
// function(_initialize) {}
Function {
span: DUMMY_SP,
params: iter::once(initialize.into())
.chain(super_class_ident.map(Pat::from))
.map(|pat| Param {
span: DUMMY_SP,
decorators: Vec::new(),
pat,View on GitHub (pinned to 5176682b65)