feat: WIP enums implementation

[load1n9]

Enums support only when using the typescript flag

[eliassjogreen]

Remember that const enum and enum are compiled differently. I wonder if there are any TypeScript tests we could run for enums? Anyways here's the documentation for how enums are compiled.

[DonIsaac]

Quick question: does this mean Nova is attempting to support most/all TypeScript syntax? e.g. is native namespace support planned?

[load1n9]

the idea is to make it a feature not enabled by default

[aapoalas]

Quick question: does this mean Nova is attempting to support most/all TypeScript syntax? e.g. is native namespace support planned?

My thinking is that Rust feature flags shall be our friends. I'm planning on writing a blog post about this as well, but TypeScript support at the parsing level (at least) is the first one of our supported feature flags.

There hasn't really been a direct discussion on this, but most likely TS support will not include any optimisation based on types, not at least for the foreseeable future. Our bytecode machine doesn't really give much in the way of type based optimisations in the first place. But our parser, oxc's parser, supports TS out of the box and for us supporting TS mostly just means skipping the type declarations. As a result, it's an easy feature to support.

Side note: In no particular order, other feature flags I'm thinking about:

• No array indexed property accessors and holes. (Allows array algorithms to be aggressively optimised, while breaking cases that basically only exist in conformance tests.)
• No object hierarchy: Arrays are Arrays and not Objects. ArrayBuffers are only ABs, etc. Breaks assigning properties to these types. Breaks subtyping of all non-ordinary object classes. Breaks a lot of code. Enables a much slimmer JS variant that may be useful in certain circumstances.
• Immutable prototypes. Prototype object, once created, is immutable. Breaks code that messes with prototypes. Makes prototype method lookup almost trivially easy.