Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eslint-plugin: write rules in TypeScript #11

Open
utarwyn opened this issue Apr 7, 2023 · 2 comments
Open

eslint-plugin: write rules in TypeScript #11

utarwyn opened this issue Apr 7, 2023 · 2 comments
Labels
🚀 enhancement New feature or request

Comments

@utarwyn
Copy link
Member

utarwyn commented Apr 7, 2023

ESLint exports a package @types/eslint with typings of the whole linter. This can simplify the writing of rules with autocompletion and typing verification.

This idea has been proposed during the challenge, and I think it's a good idea to look into it.
Maybe we should use it? What do you think of this?

@utarwyn utarwyn added 🚀 enhancement New feature or request javascript labels Apr 7, 2023
@AMorgaut
Copy link

AMorgaut commented Aug 21, 2024

Well, I both like and dislike TypeScript

TypeScript adds boilerplate that can quickly become cumbersome with added necessary build time
Moreover, according to a well-knowned study (which would probably need an update), TypeScript was calculated as 4 times more energy consumming than JavaScript

Comparison to C

  • JavaScript: 4.45x
  • TypeScript: 21.5x

image

I usually prefered JSDoc where necessary. Nowadays, when IDEs don't do it natively, you should be able to also use TypeScript or the lighter flow to do typechecking and get autocompletion on regular JavaScript.

Both support "type inference" (which means that they detect the type of a variable / property based on the value it was initialized with)

TypeScript also supports part of JSDoc

Of course it's not as advanced as coding in TypeScript but energy impact and code complexity are lighter

See

@utarwyn
Copy link
Member Author

utarwyn commented Sep 13, 2024

The idea was to use TypeScript for the development of the plugin, but I agree that this will come with advantages and disavantages:

  • ➕➕➕: TypeScript is typed by definition, so it will be much easier to write new rules. We are currently using JSDoc but this does not work very well in code editors and its hard to navigate through nodes without a lot of debugging.
  • ➕➕: the code is also more reliable and more maintenable
  • ➖: runtime code can be a bit more energy consumming (even if this is better as time goes - it builds more or less the same code as the JS one), but I think the main energy consumption happens during the build time, so not a big deal?

I understand your position but I think that the "ecological" cost of using TypeScript is not so bad, compared to the productivity boost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚀 enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants