proposal-type-annotations VS astexplorer

After almost a decade of TypeScript my recommendation is to not use TypeScript enums.

Enums is going to make your TypeScript code not work in a future where TypeScript code can be run with Node.js or in browser when typings are added to JavaScript[1]

Enums results in runtime code and in most cases you really want type enums. Use `type State = "Active" | "Inactive"` and so on instead. And if you really want an closed-ended object use `const State = { Active: 1, Inactive: 0 } as const`

[1] https://github.com/tc39/proposal-type-annotations

Maybe as part of the Flutter/Dart sales story?

Here is the current status of the standard proposal.

https://tc39.es/proposal-type-annotations/

So read the Github of TC39: https://github.com/tc39/proposal-type-annotations

Yes. That is noted in the PR:

> There is a TC39 proposal for type annotations

Which links to https://github.com/tc39/proposal-type-annotations

It is a long ways off though.

IMO the game changer in your scenario is when type annotations are added as a standard JS feature:

https://github.com/tc39/proposal-type-annotations

At that point you'd be able to run your TS code directly without any transpiration necessary. I'd love to remove all the build process junk from my projects and have them run quicker.

That proposal is not fully compatible with Typescript: https://github.com/tc39/proposal-type-annotations?tab=readme...

They held a meeting a few months ago so it's alive but probably still years away.

https://github.com/tc39/proposal-type-annotations/issues/184

I particularly like this thread in the TC39 types proposal. TypeScript IS a development trojan horse and locks you into the Microsoft Way of being a JS developer.

Edit: There is a proposal to extend JavaScript with type annotations, which would allow ("a reasonably large subset") of TypeScript to run directly in the browser. Yay!

https://github.com/tc39/proposal-type-annotations

There are different solutions for working with JS code, with differences in the final AST. In this article, we will use babel for this purpose. You don't need to install anything, you can experiment with everything on such resource as astexplorer.

astexplorer

https://astexplorer.net - a helpful tool to see the AST version of your code ESLint Selectors - the list of selectors typescript parser playground. astexplorer analogue for typescript. It has an essential feature: ESQuery filter. It allows you to debug your selectors in real-time.

You can play with your code here, and visualise ASTs for the same.

Website

To understand this syntax, I recommend exploring AST Explorer. You will have a better view of how the AST of JavaScript works and how to correlate it with the Eslint syntaxy:

You can never mistake type_declaration with an identifier, otherwise the program will not work. Aside from that constraint, you are free to name them whatever you like, there is no one standard, and each parser has it own naming conventions, unless you are planning to use something like LLVM. If you are interested, you can see examples of naming in different language parsers in the AST Explorer.

The rule that I want to write will be called not-allows-underscore: the idea is to abolish the use of underscores when declaring variables or functions. It's a real dummy rule, but it should be enough to see in action the concepts that we have discussed earlier. The first thing that I would do is to go to AST Explorer, write down a code that declares variables and functions (both standard and arrows one) and take a look at what type of node is the one that encodes the identifier. Doing that, I found out that the node type of my interest is Identifier, what a surprise! 🤣. In particular, the structure of the node holds the string used as identifier in the name property.

All the information about the API, AST node names, AST Explorer, etc. you can read in the official documentation. I’m just going to show examples of how to automate the check-up of our created conventions.