-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathtypescript.js
78 lines (77 loc) · 2.83 KB
/
typescript.js
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
76
77
78
import eslintPluginImport from "eslint-plugin-import";
import tseslint from "typescript-eslint";
import {typescriptExtensions, typescriptExtensionsFiles} from "../files.js";
export default tseslint.config(
{
// Apply to TypeScript files
files: typescriptExtensionsFiles,
// Extend default sharable configs
extends: [
tseslint.configs.recommendedTypeChecked,
tseslint.configs.stylisticTypeChecked,
// Add rules for importing using TypeScript
eslintPluginImport.flatConfigs.typescript,
],
languageOptions: {
parserOptions: {
projectService: true,
},
},
rules: {
/*
TypeScript rules
Supported rules: https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin#supported-rules
*/
// Reason: Organization
"@typescript-eslint/member-ordering": "error",
// Reason: Avoids confusing angle bracket assertions with TSX syntax (this is not the same as type parameters)
"@typescript-eslint/consistent-type-assertions": [
"error",
{
"assertionStyle": "as",
},
],
// Reason: Report unused variables but allow omitting vars from objects like `{badProp, ...otherProps} = props`
"@typescript-eslint/no-unused-vars": [
"error",
{
"ignoreRestSiblings": true,
},
],
// Reason: `??` and `||` are different operations to me, and I do not struggle with switching between them
// - `??` is great for defaulting, and `||` is great for normalization of "" for situations where "" means
// effectively null, like a form input
"@typescript-eslint/prefer-nullish-coalescing": "off",
// Reason: `type` and `interface` are not fully interchangeable over the corse of the codebase's lifetime
// - While `interface` as a default is my preferred style, this rule doesn't know my intent behind using
// `type` for an object type like a reducer action, where I plan to use a union or intersection when
// another action is added. And I value my intent over the style option of one keyword, semicolon, and
// equals sign.
"@typescript-eslint/consistent-type-definitions": "off",
},
},
{
// Apply to TypeScript JSX files
files: [
"**/*.tsx",
],
rules: {
// Reason: Extends clauses can be used to prevent parsing issues with arrow functions with type parameters
"@typescript-eslint/no-unnecessary-type-constraint": "off",
},
},
{
// Apply to TypeScript test files
files: [
`**/*.test.{${typescriptExtensions}}`,
],
rules: {
// Reason: Mocking and stubbing in tests often include empty functions
"@typescript-eslint/no-empty-function": "off",
// Reason: Remove unbound method rule to delegate to `jest/unbound-method` to automatically allow certain
// unbound methods that are safe in tests
// - Fails silently, so is safe to use in JavaScript
"@typescript-eslint/unbound-method": "off",
},
},
);