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 #168

Merged
merged 26 commits into from
Jun 28, 2024
Merged

ESLint #168

merged 26 commits into from
Jun 28, 2024

Conversation

lishaduck
Copy link
Contributor

@lishaduck lishaduck commented Jun 22, 2024

This is very much a WIP.
I'm working on modernizing the linting configuration now that node 10&12 are dropped.

I have a few stylistic questions, but first I want to get tests passing.

@lishaduck
Copy link
Contributor Author

lishaduck commented Jun 22, 2024

Oh, tests pass now 🤷‍♂️
Whatever jest. 😆

And they don't again, after a force-push with 0 changes. 🤣

@lishaduck lishaduck changed the title Eslint ESLint Jun 22, 2024
@lishaduck

This comment was marked as outdated.

@lishaduck
Copy link
Contributor Author

Also, this is going to conflict with #147. Do you want me to see how much I can port from that PR?

@jfmengels
Copy link
Owner

@lishaduck That sounds good to me. I'm not sure what to do about that PR at the moment (I'm also not sure as to the state I left it in to be honest). But feel free to postpone that porting to after this gets merged, we can sort the conflicts later 🤷‍♂️

@lishaduck lishaduck marked this pull request as ready for review June 22, 2024 17:18
@lishaduck
Copy link
Contributor Author

lishaduck commented Jun 22, 2024

Ok! ESLint v9 doesn't support Node 16, so we're still on 8.
ESLint plugins have followed suit, so we're lagging a few versions behind XO, n, and Unicorn. I also didn't add JSDoc b/c @import is only supported in node 18+, so it warns (and you can't comment in jsdocs).
Otherwise, I think it's all up to date.

PS: I know you don't like expiring todos (and I agree with your logic!), but I think these are fine, given how they work.

@lishaduck
Copy link
Contributor Author

lishaduck commented Jun 22, 2024

This should be good to go! Nope. Nonetheless:

Follow ups:

Also:

  • npm dedupe
  • Improve GHA (security, up-to-date, and matrix)
  • Cache TS and ESLint

@lishaduck
Copy link
Contributor Author

Moving this back to WIP.
Those flakes were updated snapshots, now I have to go back through everything.
Also, I realized that the XO cli does a lot more than the config, so I'll fun with that :)
Do you mind if I make a TODO list issue? Both so I remember what needs to get done, but also so you can see what I'm working on?

@lishaduck lishaduck marked this pull request as draft June 23, 2024 02:41
@jfmengels
Copy link
Owner

Moving this back to WIP.

Sure. Let's focus on getting it merged again if that's alright with you (and do unrelated work to that in a separate PR).

Do you mind if I make a TODO list issue?

Sure, go ahead.

Enable prefer-await-to-then?

I'd say not, I find that .then does provide some purpose even in the presence of await. For instance, with the rule you can't write this

promises = await Promise.all([
    someFunction(data).then(doSomething),
    someOtherPromise,
    ...
]);

which can be useful if you want to do more things in parallel. Or just a = await someFunction(data).then(doSomething) to avoid intermediate variable declarations.

I realized that the XO cli does a lot more than the config, so I'll fun with that :)

Yes, it does a bit more, though I don't remember what it did. To be honest, I don't think we need to add too many ESLint rules and other tools (but feel free to suggest them!), I mostly want to help avoid regressions, and get some more guarantees here and there so that this project is maintainable and bug-free.

So far (surprisingly), the migration to TS has not caught any noticeable bugs, so the investment has been quite poor. Not that we shouldn't continue (especially if it's a bit fun for some people 😄). The XO rules can definitely wait I'd say (although, I'm not sure what has now been disabled).

@lishaduck
Copy link
Contributor Author

lishaduck commented Jun 23, 2024

Moving this back to WIP.

Sure. Let's focus on getting it merged again if that's alright with you (and do unrelated work to that in a separate PR).

Yeah. I just want to fix tests and the lints I realized weren't getting applied right.
That other comment was just a general todo list.

Do you mind if I make a TODO list issue?

Sure, go ahead.

👍

Enable prefer-await-to-then?

I'd say not, I find that .then does provide some purpose even in the presence of await. For instance, with the rule you can't write this

promises = await Promise.all([
    someFunction(data).then(doSomething),
    someOtherPromise,
    ...
]);

which can be useful if you want to do more things in parallel. Or just a = await someFunction(data).then(doSomething) to avoid intermediate variable declarations.

Yeah. I tried turning it on but ran into that, so I wasn't sure.

I realized that the XO cli does a lot more than the config, so I'll fun with that :)

Yes, it does a bit more, though I don't remember what it did. To be honest, I don't think we need to add too many ESLint rules and other tools (but feel free to suggest them!), I mostly want to help avoid regressions, and get some more guarantees here and there so that this project is maintainable and bug-free.

Essentially, it applies the plugins, so migrating to the config turned off a lot of important rules, like eslint-plugin-n (with eslint-plugin-es-x), for example.

So far (surprisingly), the migration to TS has not caught any noticeable bugs, so the investment has been quite poor. Not that we shouldn't continue (especially if it's a bit fun for some people 😄).

It's a lot of fun :)
Once this lot is finished, I plan on finished ts-ifying the rest.
It's certainly helpful to the extent of maintenance, as TSEslint 6 caught a good deal. It's still local for now until I finish unicorn and n, but it's definitely a good investment. And I turned off the abusive promises rules! Lots of stuff to fix (though mostly modernization and theoretical data races, not actual bugs).

The XO rules can definitely wait I'd say (although, I'm not sure what has now been disabled).

Unicorn was off, but I've almost finished reenabling it. N needs to get on. We don't use AVA, so that can remain off.

@lishaduck
Copy link
Contributor Author

Ooooh. Unicorn found a unicode bug!
Probably not a real issue, but String.prototype.split() breaks apart surrogate pairs.

lishaduck and others added 3 commits June 24, 2024 17:26
Make Jest run less often.
Before now, Jest would run on every change.

Also, ESLint now fails on warnings.
See (jfmengels#163)[jfmengels#163 (comment)]

Co-authored-by: Jeroen Engels <jfm.engels@gmail.com>
@lishaduck
Copy link
Contributor Author

lishaduck commented Jun 24, 2024

🤞 I think I'm done.

P.S: Sorry for the diff 🙃
I just read it all. Took me a good 5 minutes, and I was just skimming. Not fun. At least it was mostly automated.

@lishaduck lishaduck marked this pull request as ready for review June 24, 2024 22:27
@lishaduck lishaduck mentioned this pull request Jun 25, 2024
package.json Outdated Show resolved Hide resolved
@jfmengels
Copy link
Owner

jfmengels commented Jun 26, 2024

Thank you for all the changes @lishaduck. I hope it will help make the project more maintainable ☺️

I'm happy to merge as-is (or rather "rebase fast-forward" the branch manually outside of GitHub, to avoid you needing to rebase the other PRs) and delay the remaining feedback for another PR, would you prefer that?

@lishaduck
Copy link
Contributor Author

Thank you for all the changes @lishaduck. I hope it will help make the project more maintainable ☺️

I'm happy to merge as-is (or rather "rebase fast-forward" the branch manually outside of GitHub, to avoid you needing to rebase the other PRs) and delay the remaining feedback for another PR, would you prefer that?

Eh, I don't mind rebasing, but if you'd prefer that I don't really care.

@jfmengels
Copy link
Owner

I'll let you make the remaining changes then 👍

lishaduck added 23 commits June 26, 2024 22:45
`eslint-plugin-n` is the maintained version of `eslint-plugin-node`.
Now that we only support Node 14.18 and later, we can use `node:`.
I just realized that I'd reverted the bump to Node 14.18.
As I've gotten stuff dependent on 14.18 merged, I'm bumping it again.
Oops. At least it's only a single minor.

This also allows `node:` to stay.
XO removed it a while back, but it now supports ESLint 8.
This replaces `util.promisify` with `fs.promises` for all asynchronous operations.
This also switches from `node:fs` to `graceful-fs` for all synchronous operations.
When possible, we now use async/await rather than callbacks.
While a slight performance hit is likely incurred, the code is much more consistent.
More Promise-based apis are available now than used to be the case.
Replace some jarring .then() chains with `async`/`await`.
Well, technically, it's @eslint-community/eslint-plugin-eslint-comments.
Same difference. And hey, it caught something!
I hadn't previously realized that they didn't drop Node 16 until v7.
The plugin requires a newer version of Node to run on ESLint v8.
Also, I ran `npm pkg fix`. It didn't find anything.

In conclusion, I sorted the package.json file via `npx sort-package-json`.
This makes try/catch more predictable.
I figured this was a hangover.
prettier/prettier is already removed.
Unicorn renamed these rules a long time ago.
`*` is an "explicit any!"
Continue making sure the code works everwhere.
Maybe ESM someday, but for now...
Turbo kills them otherwise, which is often fine, but breaks `test-run`.
@jfmengels jfmengels merged commit 9dec6b7 into jfmengels:main Jun 28, 2024
3 checks passed
@lishaduck lishaduck deleted the eslints branch June 28, 2024 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants