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.

Sign up for GitHub

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

Gm/update-base-and-readme #32

Merged
merged 2 commits into from
Sep 30, 2024
Merged

Gm/update-base-and-readme #32

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
37f40a0
add new rules to base config
mckelveygreg Sep 17, 2024
b70c0ad
fix readme example
mckelveygreg Sep 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@
## Usage

```js
import { baseConfig, reactConfig } from "@20i/eslint-config"
import baseConfig from "@20i/eslint-config"
import reactConfig from "@20i/eslint-config/react"
import pluginQuery from "@tanstack/eslint-plugin-query"
import tsEslint from "typescript-eslint"

Expand Down
26 changes: 26 additions & 0 deletions eslint.config.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,32 @@ export default tsEslint.config(
"@typescript-eslint/consistent-type-exports": "error",
"@typescript-eslint/no-import-type-side-effects": "error",
"@typescript-eslint/consistent-type-imports": "error",
"@typescript-eslint/use-unknown-in-catch-callback-variable": "off",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Things I think are true:

  • errors should be unknown
  • your tsconfig settings should be strict

Things I want to be true:

  • that ts setting works in then().catch() (it does not yet)
  • I don't have to fix it myself (apparently you can override the global, but i don't want to do that.

Therefore, I don't think this rule is important enough (and i don't feel like making that many code changes to support it 😬 )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't say I've encountered this but your answer seems reasonable to me.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TS made the unknown thing a default a bit ago, and I got wrecked with a refactor of tons of tiny changes from any to unknown. But apparently, that was only for try/catch, not then().catch()

So we wait on...

"@typescript-eslint/restrict-template-expressions": [
"error",
{
allowAny: true,
allowBoolean: true,
allowNullish: false,
allowNumber: true,
allowRegExp: true,
},
],
Comment on lines +38 to +47
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This rule I catches some nice little bugz that happen inside template literals, like [object] [object] and encourages you to provide fallbacks for nullish values.

Template literals will call the .toString() method on everything you put there, so with that understanding, I think it is fine to allow the above values, as toString() was not adding any value having that enforced.
However, it did make me consider numbers, as most numbers can be handled fine by toString(), big numbers in UI should be displayed with .toLocaleString(), and any floating point math should be dealt with before you end up with ugly 3.0000000000000001.

I kept the allowNullish: false however. The more time that goes by, the more I'm bothered by my logs that end up with: "error with item id:" where the item didn't exist or something. This rule would ask the developer to provide some feedback, like

`error with item id: ${item?.id ?? "<item not found>"}`

https://typescript-eslint.io/rules/restrict-template-expressions/

"@typescript-eslint/no-confusing-void-expression": [
"error",
{
ignoreArrowShorthand: true,
ignoreVoidOperator: true,
},
],
Comment on lines +48 to +54
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I started my journey here without the overrides. And then like 50 files in... it started to feel a bit overboard...

The core of this rule supports lots of good patterns, but for these 2 overrides, i feel like I'm comfortable not going all the way.

This means, we can still:

<button onClick={() => console.log("🎉")} />

https://typescript-eslint.io/rules/no-confusing-void-expression/

"@typescript-eslint/no-unused-expressions": [
"error",
{
allowShortCircuit: true,
allowTernary: true,
enforceForJSX: true,
},
],
Comment on lines +55 to +62
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, this one was a bit funky. Essentially it is trying to protect you from misunderstanding function calls, but it went a little far. They provided the above overrides, which maintained our current coding style, while adding som protection when you actually do something wrong.

https://eslint.org/docs/latest/rules/no-unused-expressions#options

},
languageOptions: {
globals: {
Expand Down