Support emitting typescript decorator metadata

[monoclex]

For projects such as TypeORM, it is necessary for decorator metadata to get emitted. For example, let's take TypeORM's typescript-example project. Running the project normally yields the following output.

git clone https://github.com/typeorm/typescript-example --depth 1
cd typescript-example
yarn && yarn start

Attempting to use ESBuild successfully compiles it with warnings, but fails with a runtime error.

esbuild --bundle --outfile=index.js --target=esnext --platform=node --format=cjs --strict .\src\index.ts

[evanw]

The emitDecoratorMetadata flag is intentionally not supported. It relies on running the TypeScript type checker, which relies on running the TypeScript compiler, which is really slow. Given that esbuild's primary purpose is speed, I will not be integrating the TypeScript compiler into esbuild. I will also not be rewriting the TypeScript type checker in Go since that would be a massive ongoing maintenance burden. It's possible that you could write an esbuild plugin for this when esbuild's plugin API materializes (see #111) but that would likely eliminate most of the speed advantage of using esbuild in the first place. You're probably better off using another tool instead of esbuild if you need to do this.

[monoclex]

What do you think about adding some way to short circuit the type checking process, such as an @esbuild-type [number/string/object/boolean/function] annotation? That could be a solution for this situation specifically at least, but I'm not sure about the versatility of the idea at a larger scope. It's certainly not an ideal solution and is at best a hack, but if it could be useful in other areas that'd be a great side effect.

EDIT: a little explanation on how an @esbuild-type would help implementing this specifically:
The following TS class

import { Column, Entity, PrimaryGeneratedColumn } from "typeorm";

@Entity()
export class TestModel {

  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  data!: string;

  @Column()
  complicated!: SomethingComplicated<string, number, Record<string, unknown>>

  @Column()
  a!: boolean;

  @Column()
  a2!: Function;
}

interface SomethingComplicated<T, U, V> {
  a: T;
  u: SomethingComplicated<T, U, V>[];
  v: V[]
}

will be transpiled to the following JS

// ...
const typeorm_1 = require("typeorm");
let TestModel = class TestModel {
};
__decorate([
    typeorm_1.PrimaryGeneratedColumn(),
    __metadata("design:type", Number)
], TestModel.prototype, "id", void 0);
__decorate([
    typeorm_1.Column(),
    __metadata("design:type", String)
], TestModel.prototype, "data", void 0);
__decorate([
    typeorm_1.Column(),
    __metadata("design:type", Object)
], TestModel.prototype, "complicated", void 0);
__decorate([
    typeorm_1.Column(),
    __metadata("design:type", Boolean)
], TestModel.prototype, "a", void 0);
__decorate([
    typeorm_1.Column(),
    __metadata("design:type", Function)
], TestModel.prototype, "a2", void 0);
// ...

thus, implementing specifically those 5 types would solve it for only reflect-metadata stuff, but I'm unaware of any other scenarios where it'd be beneficial to everyone at large.

[evanw]

That annotation seems too much of a special-case to put into esbuild core to me. Besides, if you want to be able to do this:

class Foo {
  @decorator
  // @esbuild-type number
  prop: number
}

couldn't you just do something like this instead?

class Foo {
  @decorator
  @esbuildType(Number)
  prop: number
}

where esbuildType is just a function that forwards to the TypeScript metadata function:

let esbuildType = t => __metadata("design:type", t)

I think that would do what you're trying to accomplish without needing to extend esbuild at all. In fact it's even shorter than the comment annotation form.

I know implementing just those types would be part of the feature, but I don't think it's a good idea to claim to support it and then work differently in subtle ways that silently break things. Even those primitive types can be propagated through arbitrary aliases and type expressions in the type system and can probably be imported from other files. Getting all of that correct means re-implementing the TypeScript type checker.

[monoclex]

Alright, that's completely understandable. Thanks for taking the time to run through the idea 👍

[axe-me]

I saw swc actually support emitDecoratorMetadata. This is how it did it: https://github.com/swc-project/swc/pull/939/files
Would esbuild so something similar?
lots of backend packages are built on top of this flag. it's kinda annoying not able to use esbuild to improve backend DX.

Thanks.

[evanw]

This is in scope for swc because they are trying to replicate the whole TypeScript type system in swc. Putting a type system into esbuild is firmly out of scope for esbuild. If you need this feature you should use swc/spack instead (or maybe use swc as a plugin for esbuild?).

[shadowtime2000]

@evanw I am pretty sure that the SWC project to replicate tsc is a closed source one, while the open source parts of SWC support emitDecoratorMetadata so that may not be the case, but I am not 100% sure.

[evanw]

Ah weird. Ok well I guess never mind. I missed that part. Looks like this is the relevant comment: swc-project/swc#571 (comment)

But it’s not open sourced, and I’m not going to open source it.

[shadowtime2000]

@evanw Do you think it may still be possible considering how the parts of SWC which act just like Babel are able to do it?

[thomaschaaf]

I'm currently trying to write an esbuild plugin which will try to build with esbuild and compile only the files containing docorators with tsc again. This should result in faster build times as usually not all files use decorators. See #915 (comment)

[thomaschaaf]

I have released the following plugin: esbuild-plugin-tsc which allows you to now use emitDecoratorMetadata with esbuild.

[vikasgarghb]

@evanw Is there any workaround to this issue?
@SirJosh3917 What solution did you go for?