2017-06-11 08:32:59 +00:00
|
|
|
module.exports = {
|
|
|
|
"root": true,
|
|
|
|
"env": {
|
|
|
|
"node": true,
|
|
|
|
"es6": true
|
|
|
|
},
|
|
|
|
|
2020-04-14 11:08:52 +00:00
|
|
|
"parser": "@typescript-eslint/parser",
|
2017-06-11 08:32:59 +00:00
|
|
|
|
2020-04-09 05:56:25 +00:00
|
|
|
"plugins": [
|
2020-04-14 11:08:52 +00:00
|
|
|
"mocha",
|
2020-04-28 13:16:28 +00:00
|
|
|
"@typescript-eslint",
|
|
|
|
"unicorn"
|
2020-04-09 05:56:25 +00:00
|
|
|
],
|
|
|
|
|
2020-05-07 10:54:55 +00:00
|
|
|
"extends": [
|
|
|
|
"plugin:prettier/recommended"
|
|
|
|
],
|
|
|
|
|
2017-06-11 08:32:59 +00:00
|
|
|
"rules": {
|
2020-05-07 10:54:55 +00:00
|
|
|
// Error if files are not formatted with Prettier correctly.
|
|
|
|
"prettier/prettier": 2,
|
2017-06-11 08:32:59 +00:00
|
|
|
// syntax preferences
|
|
|
|
"quotes": [2, "single", {
|
|
|
|
"avoidEscape": true,
|
|
|
|
"allowTemplateLiterals": true
|
|
|
|
}],
|
|
|
|
"spaced-comment": [2, "always", {
|
|
|
|
"markers": ["*"]
|
|
|
|
}],
|
|
|
|
"eqeqeq": [2],
|
|
|
|
"accessor-pairs": [2, {
|
|
|
|
"getWithoutSet": false,
|
|
|
|
"setWithoutGet": false
|
|
|
|
}],
|
|
|
|
"new-parens": 2,
|
|
|
|
"func-call-spacing": 2,
|
2017-08-21 23:39:04 +00:00
|
|
|
"prefer-const": 2,
|
2017-06-11 08:32:59 +00:00
|
|
|
|
2020-06-19 14:39:03 +00:00
|
|
|
"max-len": [2, {
|
|
|
|
/* this setting doesn't impact things as we use Prettier to format
|
|
|
|
* our code and hence dictate the line length.
|
|
|
|
* Prettier aims for 80 but sometimes makes the decision to go just
|
|
|
|
* over 80 chars as it decides that's better than wrapping. ESLint's
|
|
|
|
* rule defaults to 80 but therefore conflicts with Prettier. So we
|
|
|
|
* set it to something far higher than Prettier would allow to avoid
|
|
|
|
* it causing issues and conflicting with Prettier.
|
|
|
|
*/
|
|
|
|
"code": 200,
|
|
|
|
"comments": 90,
|
|
|
|
"ignoreTemplateLiterals": true,
|
|
|
|
"ignoreUrls": true,
|
|
|
|
"ignoreStrings": true,
|
|
|
|
"ignoreRegExpLiterals": true
|
|
|
|
}],
|
2017-06-11 08:32:59 +00:00
|
|
|
// anti-patterns
|
2017-06-22 20:38:10 +00:00
|
|
|
"no-var": 2,
|
2017-06-11 08:32:59 +00:00
|
|
|
"no-with": 2,
|
|
|
|
"no-multi-str": 2,
|
|
|
|
"no-caller": 2,
|
|
|
|
"no-implied-eval": 2,
|
|
|
|
"no-labels": 2,
|
|
|
|
"no-new-object": 2,
|
|
|
|
"no-octal-escape": 2,
|
|
|
|
"no-self-compare": 2,
|
|
|
|
"no-shadow-restricted-names": 2,
|
|
|
|
"no-cond-assign": 2,
|
|
|
|
"no-debugger": 2,
|
|
|
|
"no-dupe-keys": 2,
|
|
|
|
"no-duplicate-case": 2,
|
|
|
|
"no-empty-character-class": 2,
|
|
|
|
"no-unreachable": 2,
|
|
|
|
"no-unsafe-negation": 2,
|
|
|
|
"radix": 2,
|
|
|
|
"valid-typeof": 2,
|
2017-12-08 00:37:22 +00:00
|
|
|
"no-unused-vars": [2, { "args": "none", "vars": "local", "varsIgnorePattern": "([fx]?describe|[fx]?it|beforeAll|beforeEach|afterAll|afterEach)" }],
|
2017-08-22 21:18:07 +00:00
|
|
|
"no-implicit-globals": [2],
|
2017-06-11 08:32:59 +00:00
|
|
|
|
|
|
|
// es2015 features
|
|
|
|
"require-yield": 2,
|
|
|
|
"template-curly-spacing": [2, "never"],
|
|
|
|
|
2020-04-09 05:56:25 +00:00
|
|
|
// ensure we don't have any it.only or describe.only in prod
|
2020-04-28 13:16:28 +00:00
|
|
|
"mocha/no-exclusive-tests": "error",
|
|
|
|
|
|
|
|
// enforce the variable in a catch block is named error
|
|
|
|
"unicorn/catch-error-name": "error"
|
2020-04-14 11:08:52 +00:00
|
|
|
},
|
|
|
|
"overrides": [
|
|
|
|
{
|
2020-04-16 13:59:28 +00:00
|
|
|
"files": ["*.ts"],
|
2020-04-14 11:08:52 +00:00
|
|
|
"extends": [
|
|
|
|
'plugin:@typescript-eslint/eslint-recommended',
|
|
|
|
'plugin:@typescript-eslint/recommended',
|
2020-04-16 13:59:28 +00:00
|
|
|
],
|
|
|
|
"rules": {
|
|
|
|
"no-unused-vars": 0,
|
|
|
|
"@typescript-eslint/no-unused-vars": 2,
|
|
|
|
"semi": 0,
|
2020-04-17 09:32:56 +00:00
|
|
|
"@typescript-eslint/semi": 2,
|
2020-04-21 08:20:25 +00:00
|
|
|
"@typescript-eslint/no-empty-function": 0,
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
"@typescript-eslint/no-use-before-define": 0,
|
2020-06-23 11:55:42 +00:00
|
|
|
// We have to use any on some types so the warning isn't valuable.
|
|
|
|
"@typescript-eslint/no-explicit-any": 0,
|
|
|
|
// We don't require explicit return types on basic functions or
|
|
|
|
// dummy functions in tests, for example
|
|
|
|
"@typescript-eslint/explicit-function-return-type": 0,
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
// We know it's bad and use it very sparingly but it's needed :(
|
2020-04-28 14:06:43 +00:00
|
|
|
"@typescript-eslint/ban-ts-ignore": 0,
|
|
|
|
"@typescript-eslint/array-type": [2, {
|
|
|
|
"default": "array-simple"
|
|
|
|
}]
|
2020-04-16 13:59:28 +00:00
|
|
|
}
|
2020-04-14 11:08:52 +00:00
|
|
|
}
|
|
|
|
]
|
2017-06-11 08:32:59 +00:00
|
|
|
};
|