feat(plugin-react): add decorators option

[aleclarson]

Using decorator syntax is common enough to warrant an easier way to enable it.

Before:

react({
  babel: {
    parserOpts: { plugins: ['decorators-legacy'] }
  }
})

…or by using https://babeljs.io/docs/en/babel-plugin-syntax-decorators

After:

react({
  decorators: { legacy: true },
  // or
  decorators: { beforeExport: true || false },
})

[sodatea]

I don't think "common" usage is enough to justify a shorthand option.

dangerouslySetInnerHTML is also commonly used, but it was assigned a lengthy name in purpose.
IMO, decorators should be treated like that, too.

[aleclarson]

Hi @sodatea

dangerouslySetInnerHTML is also commonly used, but it was assigned a lengthy name in purpose.
IMO, decorators should be treated like that, too.

Hmm, this argument isn't very convincing IMO. ^^ Could you explain the negative outcomes you foresee?

---

Esbuild supports decorators with no configuration, so only a parser plugin is needed for decorators to work with plugin-react. It's better if we don't burden users with this information, and instead apply it for them.

In fact, I wonder if enabling decorator syntax by default would cause any issues? If not, we should do that.

Side note: I just learned that Esbuild implements TypeScript's decorator syntax (source), so the decorators option could actually just be a boolean, and we would use { legacy: true } behind the scenes. The docs for babel-plugin-transform-typescript mention this about decorators:

edit: Here are the alleged differences between Babel's legacy decorators and TypeScript's decorators:

• In Babel legacy decorators, they may receive an initializer property instead of a value property, but in TypeScript there is never an initializer property, only a value property.

• In TypeScript, decorators must return a descriptor for them to be chained with other decorators on the same class element.

• In TypeScript, the previous point (decorator returning a descriptor) results in the class field (if decorator was used on a field) having [[Set]] semantics when useDefineForClassFields is set to false (otherwise many decorators would break).

• In Babel, if a legacy decorator returns a descriptor, this causes the class field to always use [[Define]] semantics, regardless of the value of the loose option for the plugin-proposal-class-properties option (which seems like a bug), which is opposite of TypeScript behavior.

• In TypeScript property decorators don't receive a descriptor, but they do in Babel.

[aleclarson]

Since Esbuild supports TypeScript decorators by default, I suggest we enable decorators-legacy parser plugin by default, but only if @babel/plugin-proposal-decorators was not provided via Babel config (which should only be the case if the user is trying to workaround the differences between Babel legacy decorators and TypeScript decorators).

[sodatea]

Could you explain the negative outcomes you foresee?

Largely the same reason that esbuild only supports TypeScript decorator but not the JavaScript decorator syntax.

• The word "legacy" in the name already tells a lot. It's a syntax that is destined to be abandoned. I think supporting such a syntax doesn't align with Vite's goal of adopting modern/standard JavaScript. Not to say that even the legacy syntax has different implementations in Babel/TypeScript, which leads to even more confusion.
• TypeScript is not JavaScript. Ultimately, we can expect the TypeScript team to continue supporting this syntax, not ship drastic changes suddenly, and provide a reasonable path for future transition to the new syntax. It is also widely dependent on (e.g. in Angular). So it's practical to support decorators in TypeScript projects.

[aleclarson]

So I've opened #5057 for automatic Babel support for decorators when experimentalDecorators: true exists in the nearest tsconfig.json file (with extends support). I think that's a reasonable solution for React TypeScript projects, at least.

• The word "legacy" in the name already tells a lot. It's a syntax that is destined to be abandoned. I think supporting such a syntax doesn't align with Vite's goal of adopting modern/standard JavaScript. Not to say that even the legacy syntax has different implementations in Babel/TypeScript, which leads to even more confusion.

Okay, due to the differences between Babel legacy decorators and TypeScript decorators, I think we should just recommend using Babel to transform decorators (with this plugin), instead of only adding the Babel parser plugin. This will avoid any confusion.