Missing compiler error (or emit bug) in another isolatedModules + emitDecoratorMetadata use case

[ethanresnick]

🔎 Search Terms

"isolatedModules" "emitDecoratorMetadata"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ

⏯ Playground Link

https://www.typescriptlang.org/dev/bug-workbench/?importHelpers=true&experimentalDecorators=true&emitDecoratorMetadata=true&target=99&module=1&isolatedModules=true&noResolve=true&lib=lib.esnext.d.ts%2Clib.decorators.legacy.d.ts&ts=5.3.2#code/PTAEAEEsGcHsBsCGAXApgEwLK3QV3qtAFAgSoAeADqgE6QC2qAdsovACKoDGsNKvxUuFY0A5qmQAuUAFEAygDkKyEmHAVqdRizacefZAOnIauVKrL1IyPb341MExOhSJjp80PiQARtMJMygA06Nx2hjTQAHQEoohcAJ4W4ABmkARMiIzGCdQAtBq8yFHIxIU0yKDIuaigAIKgALygACwA3ETJaRlZqNK40Kh5ofr2eQDu1gAWedXUJcQMlEWgAN5VNfWgAL6gKTSw9KAARFHAc0PlxQBW0McdRFd7uExcyJCwTKAAKoTIABQASjWRFAoBoElwNC+L1CaUC6FAiGgSKYCSRKIACog+Iw0DRbAZeB1tp0nlwkNAUQANEFgnhMaAmXBvXj-cC-JlA0DkaR1YGrUnbIA

💻 Code

// @isolatedModules
// @experimentalDecorators
// @target: ESNext
// @experimentalDecorators: true
// @emitDecoratorMetadata: true
// @lib: esnext,decorators.legacy
// @filename: type-export.ts
export type A = 4;

// @filename: use-decorator-with-type.ts
import { type A } from "./type-export.js";

export function Test() {
  return undefined as any as ParameterDecorator;
}

export class X {
  constructor(@Test() x: A) {}
}

🙁 Actual behavior

The key issue here is that the emitted file for use-decorator-with-type.ts looks like this:

/* ... helpers snipped ... */
export function Test() {
    return undefined;
}
let X = class X {
    constructor(x) { }
};
X = __decorate([
    __param(0, Test()),
    __metadata("design:paramtypes", [Number])
], X);
export { X };

And the problematic line is __metadata("design:paramtypes", [Number]).

Typescript manages to avoid any broken imports and produce working runtime code but the runtime code leaks information about the type of A from the other file by using Number in the metadata. This seems like a clear violation of isolatedModules, but no compiler error is emitted.

🙂 Expected behavior

TS should either emit an isolatedModules-related error or should output something more generic than Number. If the emit is changed, though, I'm not sure what the ecosystem ramifications would be, so probably this should just be an error.

Additional information about the issue

No response

[RyanCavanaugh]

This seems like a clear violation of isolatedModules, but no compiler error is emitted.

On the one hand sure, but on the other hand I'm extremely surprised to learn emitDecoratorMetadata isn't banned entirely in combination with isolatedModules in the first place. A syntax-only transpiler has effectively zero chance to eDM correctly.

I don't really understand how someone would come to set both these flags in the first place - how did you end up in this situation?

[ethanresnick]

how did you end up in this situation?

I was dropped into a legacy codebase with slow build times (and that was using emitDecoratorMetadata ), so I turned on isolatedModules to see how many errors TS would report; I wanted to get a sense of whether it'd be viable to migrate to a syntax-only transpiler. (I can also imagine a use case, though, where someone with eDM wants to eventually migrate to a syntax-only transpiler, so they'd combine emitDecoratorMetadata + isolatedModules in a betterer config or similar, so that at least new isolatedModules errors can't be created.)

A syntax-only transpiler has effectively zero chance to eDM correctly.

Honestly, swc does a pretty good job at eDM for many use cases — enough so that nestjs projects, which use eDM heavily for DI, can often use swc. But, obviously, swc can't match TS' behavior here; it just emits Object in these cases. So, it'd be nice to have a isolatedModules just flag those instances of eDM that actually aren't isolatedModules safe.