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

⛵ Port the codebase to typescript #371

Closed
scagood opened this issue Oct 30, 2024 · 10 comments
Closed

⛵ Port the codebase to typescript #371

scagood opened this issue Oct 30, 2024 · 10 comments

Comments

@scagood
Copy link

scagood commented Oct 30, 2024

This makes me think that we should port the codebase to pure TS at one point in the (near) future 🤔

CC/ @eslint-community/eslint-plugin-node

Originally posted by @MichaelDeBoey in #367 (review)

@scagood
Copy link
Author

scagood commented Oct 30, 2024

This makes me think that we should port the codebase to pure TS at one point in the (near) future 🤔

I am currently in the jsdoc > typescript camp for a few reasons:

  1. Any transform causes more problems in the future than they solve now
  2. I prefer adding documentation lines to functions, meaning I have to make a jsdoc block anyway
  3. The allowJs flag means that we can use all of typescript's typing benefits without the transpilation step.

Its not that I am not against using typescript, I just find that I prefer jsdoc 🤔

Originally posted by @scagood in #367 (comment)

@voxpelli
Copy link
Member

voxpelli commented Nov 7, 2024

I'm fully with @scagood on this – I see no reason to swap JSDoc for TS syntax – they are both first class syntaxes supported by the TypeScript type checker

@scagood
Copy link
Author

scagood commented Nov 7, 2024

I wanted to add some pros for typescript here so things are a little balanced:

  1. Making advanced types in JSDoc, while possible is sometimes cumbersome.
  2. Integrations with IDEs when using typescript directly is a little smoother (eg autocompletion of types in JSDoc blocks)
  3. typescript + JSDoc feels like a second class citizen in a few cases. For example:

@scagood
Copy link
Author

scagood commented Nov 7, 2024

@aladdin-add @MichaelDeBoey

What do you think either way?

@aladdin-add
Copy link

I like typescript + jsdoc: easier to write some advanced types, and no build needed just like before. 😄

@MichaelDeBoey
Copy link
Member

#320 Almost certainly would not have happened in full typescript

It's exactly for these kind of things that I think having this build step makes more sense

@voxpelli
Copy link
Member

voxpelli commented Nov 7, 2024

Bugs can happen anywhere in the TS type declaration generation.

If we want to guard against it then we should either manually create the type declarations or add tests for the generated ones.


We can actually remove the type declaration generation from this plugin as the only types that gets uploaded and used are the 5-10 lines of types/index.d.ts

The internal type checking is the more important and useful one.

@aladdin-add
Copy link

aladdin-add commented Nov 8, 2024

@voxpelli - it's just i did in #366.

it splitted the two things:

  1. added the package's exported typing file index.d.ts- for users. it makes it easier to review the changes.
  2. make tsc just do type-checking, it does not output files - for devs.

@scagood
Copy link
Author

scagood commented Nov 8, 2024

I am not sure I agree that because that problem was simply mitigated that was should dismiss it as not a problem 🤔


I do however think that we should test the index.js interface, especially as that will cause the exported types to be tested too.

@scagood
Copy link
Author

scagood commented Nov 8, 2024

🤔 I think I am going to close this as 'wont do' -- let me know if there is a compelling reason to re-open

@scagood scagood closed this as not planned Won't fix, can't repro, duplicate, stale Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants