feat: WIP enums implementation

[yossydev]

Still working on it…

I’ve opened a new PR since some time has passed since the original discussion. #374 cc @load1n9

[eliassjogreen]

suggestion: A good idea is probably to write unit tests for these TypeScript specific features. It's of course quite hard to keep conformance with TypeScript behaviour without dragging in the TypeScript test-suite which I don't believe we want to bother ourselves with.

Thought: There are a few tsconfig options which alter the behaviour of TypeScript const enums: preserveConstEnums, isolatedModules and erasableSyntaxOnly. We will probably need to somehow configure these for TypeScript compatability, but that is a future issue either way when it comes to compatability.

[yossydev]

suggestion: A good idea is probably to write unit tests for these TypeScript specific features. It's of course quite hard to keep conformance with TypeScript behaviour without dragging in the TypeScript test-suite which I don't believe we want to bother ourselves with.

thx!
https://github.com/oxc-project/oxc/tree/main/tasks/transform_conformance/tests/babel-plugin-transform-typescript/test/fixtures oxc's Would a transpiler test be helpful? 👀

[aapoalas]

Regarding tsconfig options, I think we'd choose one behaviour and stick with it. For enums, my personal choice would be:

1. non-const enums are actually compiled into JS objects in the way TS implements them, so two-directional objects.
2. const enums are fully inlined into all use-sites: Note that this means adding data into Modules if a const enum is exported, so that they can be imported and used.

Note that the latter point is kind of an interesting and magical choice. What it would mean is that code like this would work:

if (value ==== ConstEnum.Variant) {}
// becomes eg.
if (value ==== 1) {}

but this would not:

if (Object.keys(ConstEnum).includes(value)) {}
// becomes eg.
if (Object.keys((() => { throw new Error("const enum object cannot be used") })()).includes(value)) {}