fix: properly export interfaces that were typedefs

[BeksOmega]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide
• I ran npm run format and npm run lint

The details

Resolves

N/A
Follows the same strategy as #6246

Proposed Changes

Typedefs that were on classes were transformed into interfaces, but they were not properly appended to the classes they used to exist on. This fixes that, and also exports the type to match the other places where the auto-migration script changed things.

Behavior Before Change

Should be no change in behavior (besides whether these types exist or not).

Behavior After Change

Should be no change in behavior (besides whether these types exist or not).

Reason for Changes

Backwards compatibility.

Test Coverage

No manual testing necessary.

Documentation

N/A

Additional Information

I didn't include the export const E = C.E; line, because I don't believe we actually want these to be declared (at the module level) in the exported JavaScript.

[cpcallen]

I didn't include the export const E = C.E; line, because I don't believe we actually want these to be declared (at the module level) in the exported JavaScript.

The export const is only needed (along with the export type) for enums, because they are both an object and a type. For interfaces and typedefs, only the export type is needed.

[cpcallen]

Mostly fine but (as detailed below):

• One typo that needs fixing.
• Some @enums that have not (but probably should have been) converted to enum which ought to be included.
• Some missing JSDocs that could be copied over.

[BeksOmega]

Should be ready for another look.

Converted all unconverted enums, but did not export. Enums that were instance properties are also not namespace-merged (because they didn't exist on the class before).

The only thing marked as @enum previously which has not been converted to a typescript enum is measurables/types.ts, because we actually append to the "enum" in getType, which typescript does not support (cuz that's not what an enum is).

Instead measurables/types.ts is a class, which is reasonably ok. We can't use it like an enum type (we have to use number) which sucks. But I we weren't using it as a type anywhere anyway, so it's not a huge problem.

---

Probably best to review the latest three commits separately, since they do different things.

[BeksOmega]

The typescript compiler did not like zelos overriding the SHAPES property with its own enum, because the types were unrelated. So I reverted that change, but added type information to the SHAPES property, so that it is at least a little bit better than before.

[Edit: And I actually ran build:js this time, and it worked]

[cpcallen]

Converted all unconverted enums, but did not export. Enums that were instance properties are also not namespace-merged (because they didn't exist on the class before).

SGTM. Though enums as instance properties is… interesting. 🤨

The only thing marked as @enum previously which has not been converted to a typescript enum is measurables/types.ts, because we actually append to the "enum" in getType, which typescript does not support (cuz that's not what an enum is).

Yeah: that is definitely not how enums are supposed to work.

(Fun thing to think about: given the plethora of obscure languages out there, there are probably strongly dynamically typed languages where you can alter the set of values of an enum at runtime. What do they do when you delete an entry from the set? Some might coerce all values of that type to one of the remaining members. Some might throw an error if any value of that type happens to be the deleted member.)