-
Notifications
You must be signed in to change notification settings - Fork 544
/
Copy pathrecommended.js
231 lines (200 loc) · 7.54 KB
/
recommended.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
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
/*!
* Copyright (c) Microsoft Corporation and contributors. All rights reserved.
* Licensed under the MIT License.
*/
/**
* "Recommended" eslint configuration.
*
* This is the fluid-framework repository's default configuration.
* Recommended for use production packages whose APIs we do not expect the majority of our customers to use directly.
*
* For packages whose APIs are intended for wide use, the "Strict" configuration should be used instead.
*/
module.exports = {
env: {
browser: true,
es6: true,
es2024: false,
node: true,
},
extends: ["./minimal-deprecated.js", "plugin:unicorn/recommended"],
plugins: ["eslint-plugin-tsdoc"],
rules: {
// RECOMMENDED RULES
"@rushstack/no-new-null": "error",
"no-empty": "error",
"no-void": "error",
"require-atomic-updates": "error",
// This rule ensures that our Intellisense looks good by verifying the TSDoc syntax.
"tsdoc/syntax": "error",
// In some cases, type inference can be wrong, and this can cause a "flip-flop" of type changes in our
// API documentation. For example, type inference might decide a function returns a concrete type
// instead of an interface. This has no runtime impact, but would cause compilation problems.
"@typescript-eslint/explicit-function-return-type": [
"error",
{
allowExpressions: true,
allowTypedFunctionExpressions: true,
allowHigherOrderFunctions: true,
allowDirectConstAssertionInArrowFunctions: true,
allowConciseArrowFunctionExpressionsStartingWithVoid: false,
},
],
// #region `unicorn` rule overrides
// False positives on non-array `push` methods.
"unicorn/no-array-push-push": "off",
"unicorn/empty-brace-spaces": "off",
// Rationale: Destructuring of `Array.entries()` in order to get the index variable results in a
// significant performance regression [node 14 x64].
"unicorn/no-for-loop": "off",
/**
* Disabled because we will lean on the formatter (i.e. prettier) to enforce indentation policy.
* @remarks This rule also directly conflicts with prettier's formatting of nested ternary expressions.
*/
"unicorn/no-nested-ternary": "off",
/**
* Disabled due to false positives / disruptive behavior of auto-fix.
* See {@link https://github.com/sindresorhus/eslint-plugin-unicorn/issues/2018}.
* We may consider re-enabling once the above issue has been resolved.
*/
"unicorn/no-useless-spread": "off",
/**
* Disabled due to the sheer number of false positives it detects, and because it is sometimes valuable to
* explicitly denote `undefined`.
*/
"unicorn/no-useless-undefined": "off",
/**
* By default, this rule conflicts with our internal error code formats.
* Only enforce `_` separator consistency if any such separators appear in the number literal.
*/
"unicorn/numeric-separators-style": ["error", { onlyIfContainsSeparator: true }],
"unicorn/prevent-abbreviations": "off",
/**
* Disabled because we don't yet target a ES version that includes .at().
*/
"unicorn/prefer-at": "off",
/**
* Disabled because we use EventEmitter everywhere today and changing it will be a bigger change outside of lint
* rules.
*/
"unicorn/prefer-event-target": "off",
/**
* Disabled because we don't yet target a ES version that includes string.replaceAll.
*/
"unicorn/prefer-string-replace-all": "off",
/**
* Disabled because we will lean on the formatter (i.e. prettier) to enforce indentation policy.
*/
"unicorn/template-indent": "off",
/**
* Disabled because it is incompatible with prettier.
*/
"unicorn/number-literal-case": "off",
/**
* The rule seems to crash on some of our code
*/
"unicorn/expiring-todo-comments": "off",
// #endregion
/**
* Disallows the `any` type.
* Using the `any` type defeats the purpose of using TypeScript.
* When `any` is used, all compiler type checks around that value are ignored.
*
* @see https://typescript-eslint.io/rules/no-explicit-any
*/
"@typescript-eslint/no-explicit-any": [
"error",
{
/**
* For certain cases, like rest parameters, any is required to allow arbitrary argument types.
* @see https://typescript-eslint.io/rules/no-explicit-any/#ignorerestargs
*/
ignoreRestArgs: true,
},
],
/**
* Requires explicit typing for anything exported from a module. Explicit types for function return
* values and arguments makes it clear to any calling code what is the module boundary's input and
* output.
*/
"@typescript-eslint/explicit-module-boundary-types": "error",
/**
* Disallows calling a function with a value with type `any`.
* Despite your best intentions, the `any` type can sometimes leak into your codebase.
* Call a function with `any` typed argument are not checked at all by TypeScript, so it creates a
* potential safety hole, and source of bugs in your codebase.
*/
"@typescript-eslint/no-unsafe-argument": "error",
/**
* Disallows assigning any to a variable, and assigning any[] to an array destructuring. Assigning an
* any typed value to a variable can be hard to pick up on, particularly if it leaks in from an external
* library.
*/
"@typescript-eslint/no-unsafe-assignment": "error",
/**
* Disallows calling any variable that is typed as any. The arguments to, and return value of calling an
* `any`-typed variable are not checked at all by TypeScript.
*/
"@typescript-eslint/no-unsafe-call": "error",
/**
* Disallows member access on any variable that is typed as any. The arguments to, and return value of
* calling an `any`-typed variable are not checked at all by TypeScript.
*/
"@typescript-eslint/no-unsafe-member-access": "error",
/**
* Disallows returning a value with type any from a function.
*
* Despite your best intentions, the any type can sometimes leak into your codebase.
* Returned any typed values are not checked at all by TypeScript, so it creates a potential safety
* hole, and source of bugs in your codebase.
*/
"@typescript-eslint/no-unsafe-return": "error",
// #region eslint-plugin-jsdoc rules
/**
* Ensures all JSDoc/TSDoc comments use the multi-line format for consistency.
* See <https://github.com/gajus/eslint-plugin-jsdoc#user-content-eslint-plugin-jsdoc-rules-multiline-blocks>
*/
"jsdoc/multiline-blocks": ["error", { noSingleLineBlocks: true }],
/**
* Require the description (summary) component in JSDoc/TSDoc comments
* See <https://github.com/gajus/eslint-plugin-jsdoc#user-content-eslint-plugin-jsdoc-rules-require-description>
*/
"jsdoc/require-description": ["error", { checkConstructors: false }],
// #endregion
},
overrides: [
{
// Rules only for React files
files: ["*.jsx", "*.tsx"],
rules: {
// Conflicts with best practices for various React hooks.
"unicorn/consistent-function-scoping": "off",
},
},
{
// Rules for test code
files: [
"*.spec.ts",
"*.test.ts",
"**/test/**",
// TODO: consider unifying code across the repo to use "test" and not "tests", then we can remove this.
"**/tests/**",
],
rules: {
// Does not work well with describe/it block scoping
"unicorn/consistent-function-scoping": "off",
// We run most of our tests in a Node.js environment, so this rule is not important and makes
// file-system logic more cumbersome.
"unicorn/prefer-module": "off",
},
},
{
// Rules only for type validation files
files: ["**/types/*validate*Previous*.ts"],
rules: {
"@typescript-eslint/no-explicit-any": "off",
"@typescript-eslint/no-unsafe-argument": "off",
},
},
],
};