UNPKG

@epic-web/config

Version:

Reasonable ESLint configs for epic web devs

github.com/epicweb-dev/config

epicweb-dev/config

75 lines (59 loc) • 3.47 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
# New TS ESLint Rules Date: 2024-07-08 Status: accepted ## Context In [./002-minimal-eslint.md](002-minimal-eslint.md), it was stated: > At the current time, we're probably over-minimal and more rules should > probably be added. [@onemen](https://github.com/onemen) [created a discussion](https://github.com/epicweb-dev/config/discussions/7) to enable more rules for TypeScript. As a result, some rules were enabled. ## Decision Below is the justification for the rules being enabled: - `@typescript-eslint/no-misused-promises` - It's pretty easy to forget to add `await` to a promise when doing a `if (condition) { ... }` (or similar). - `@typescript-eslint/no-floating-promises` - It's pretty easy to forget to add `await` to a promise value. If you don't care about the return value, simply add `void` like so: `void deleteExpiredSessions()`. And here's the justification for those which will not be enabled: - `@typescript-eslint/require-await` - sometimes you really do want async without await to make a function async. TypeScript will ensure it's treated as an async function by consumers and that's enough for me. - `@typescript-eslint/prefer-promise-reject-errors` - sometimes you aren't the one creating the error, and you just want to propagate an error object with an `unknown` type. - `@typescript-eslint/only-throw-error` - same reason as above. However, this rule supports options to allow you to throw `any` and `unknown`. Unfortunately, in Remix you can throw `Response` objects, and we don't want to enable this rule for those cases. - `@typescript-eslint/no-unsafe-declaration-merging` - this is a rare enough problem (especially if you focus on types over interfaces) that it's not worth enabling. - `@typescript-eslint/no-unsafe-enum-comparison` - enums are not recommended or used in epic projects, so it's not worth enabling. - `@typescript-eslint/no-unsafe-unary-minus` - this is a rare enough problem that it's not worth enabling. - `@typescript-eslint/no-base-to-string` - this doesn't handle when your object actually does implement `toString` unless you do so with a class which is not 100% of the time. For example, the timings object in the epic stack uses `defineProperty` to implement `toString`. It's not high enough risk/impact to enable. - `@typescript-eslint/no-non-null-assertion` - normally you should not use `!` to tell TypeScript to ignore the null case, but you're a responsible adult and if you're going to do that, the linter shouldn't yell at you about it. - `@typescript-eslint/restrict-template-expressions` - `toString` is a feature of many built-in objects and custom ones. It's not worth enabling. - `@typescript-eslint/no-confusing-void-expression` - what's confusing to one person isn't necessarily confusing to others. Arrow functions that call something that returns `void` is not confusing and the types will make sure you don't mess something up. These each protect you from `any` and while it's best to avoid using `any`, it's not worth having a lint rule yell at you when you do: - `@typescript-eslint/no-unsafe-argument` - `@typescript-eslint/no-unsafe-call` - `@typescript-eslint/no-unsafe-member-access` - `@typescript-eslint/no-unsafe-return` - `@typescript-eslint/no-unsafe-assignment` ## Consequences It's possible some projects are breaking some of the rules we enable. It's unlikely that fixing those cases will pose much of a challenge.