static_initializer prop #47399

Activity

1. hyuzea

   added

   bugSomething isn't workingSomething isn't working

   needs triage

   on Oct 29, 2026
2. robobun

   added

   transpilerparser || printerparser || printer

   typescriptSomething for TypeScriptSomething for TypeScript

   on Oct 29, 2026
3. robobun commented on Oct 29, 2026

   

   robobun

   on Oct 29, 2026

   Last edited by robobun

   Collaborator

   More actions

   Reproduced with {"compilerOptions":{"target":"ES2020"}} in tsconfig.json: bun a.ts throws where tsc and esbuild print 11n. Bun ignores target when it picks the useDefineForClassFields default.
   Fix drafted in #47401. It waits for a maintainer decision on whether target should imply that default (see the question below).
4. robobun commented on Oct 29, 2026

   

   robobun

   on Oct 29, 2026

   Last edited by robobun

   Collaborator

   More actions

   This needs a maintainer decision before the fix can land. @Jarred-Sumner

   The report reduces to this: Bun reads only an explicit useDefineForClassFields from tsconfig.json. tsc and esbuild also derive its default from target: false below ES2022, true from ES2022 on. With {"compilerOptions":{"target":"ES2020"}} and no flag, tsc 6.0.2 and esbuild 0.21.5 print 11n for the class in this report. Bun throws. Without a tsconfig, or with target at ES2022 or above, all three throw, so that case is not a bug.

   #47401 (a port of #40924) makes Bun derive the default from target in the transpiler, the bundler, Bun.Transpiler and the AOT checker. Two things in the repo say the current behavior is deliberate:

   • src/sema/driver/compile/tests/governing_projects.rs has the test class_fields_stay_where_they_are_written_whatever_the_target, and src/sema/config/build_options.rs replaces tsc's target rule with "explicit false only" (Compile TypeScript to machine code ahead of time: bun build --compile --aot #45631).
   • The checker query fixture diagnostic-class/old-target-class-fields in test/aot/checker-queries/call-target.programs says: "bun run leaves class fields where they are written unless useDefineForClassFields is false, and a default value in front of the body, whatever the target. No rule about where tsc would move them counts."
   • The docs of Compile TypeScript to machine code ahead of time: bun build --compile --aot #45631 said "As everywhere in Bun, target and verbatimModuleSyntax don't change the code." (AOT: fixes for modules, classes and Workers, WebKit upgrade, shorter compiler docs #47129 removed that sentence when it shortened the docs.)

   The question: should a target below ES2022 with no explicit flag imply [[Set]] class fields, as tsc and esbuild do? If yes, #47401 is ready for review. If no, I will close it, and the workaround is "useDefineForClassFields": false in compilerOptions.

   One cost of "yes": with [[Set]] semantics Bun inserts the field assignments after the first top-level super() statement. A constructor whose super() is inside if/else then throws ReferenceError at new. That gap exists today with the explicit flag. tsc rejects that shape with TS2376, esbuild wraps the nested super() calls. A target below ES2022 is far more common than the explicit flag, so "yes" should close that gap in the same change.