status-im
/
sourcecred
mirror of https://github.com/status-im/sourcecred.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
sourcecred/.eslintrc.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

52 lines
1.1 KiB
JavaScript
Raw Permalink Normal View History

Add `@flow` to `.eslintrc.js` (#258) Summary: Even though it’s not really a source file, and it lives at the repository root, it might as well have typing to make sure that we don’t do anything really dumb. Test Plan: `yarn flow` still passes. wchargin-branch: flow-eslintrc
2018-05-10 19:27:46 +00:00
// @flow
Fix all lint errors, adding a lint CI step (#175) Test Plan: Run `yarn lint` and `yarn travis` and observe success. Add something that triggers a lint warning, like `const zzz = 3;`; re-run and observe failures. wchargin-branch: lint
2018-04-30 21:52:28 +00:00
module.exports = {
Prepare to enable flow-type eslint rules (#848) This commit upgrades the flow-type eslint plugin to latest, and writes new rules into the eslintrc. To keep the diff clean, the rules are disabled: I will turn them on individually (fixing errors) in followon commits. Test plan: `yarn test`. Uncommenting the lines produces many lint errors (but the linter still operates as expected).
2018-09-17 21:11:39 +00:00
parser: "babel-eslint",
Update eslint and eslint configuration This commit updates eslint from v4 to v6. In doing so, I've moved off of the create-react-app base eslint config. We were on an old version (v2) and it doesn't make sense to update to v4, as in v4 create-react-app uses typescript. Also, it didn't make sense to stay on create-react-app's v2 config, because then it had unmet peer dependency constraints on old versions of eslint. Instead, I've moved us to use the default rules for eslint, eslint-plugin-react, and eslint-plugin-flowtype. I also made some changes to the codebase to satisfy the new lint rules that came with this change. Test plan: `yarn test` passes.
2019-07-05 17:36:43 +00:00
plugins: ["flowtype", "react"],
env: {
browser: true,
es6: true,
node: true,
jest: true,
},
parserOptions: {
ecmaVersion: 2018,
sourceType: "module",
ecmaFeatures: {
jsx: true,
},
},
extends: [
"eslint:recommended",
"plugin:react/recommended",
"plugin:flowtype/recommended",
],
Fix all lint errors, adding a lint CI step (#175) Test Plan: Run `yarn lint` and `yarn travis` and observe success. Add something that triggers a lint warning, like `const zzz = 3;`; re-run and observe failures. wchargin-branch: lint
2018-04-30 21:52:28 +00:00
rules: {
Eslint, warn on prefer-const rule (#1719) "This rule is aimed at flagging variables that are declared using let keyword, but never reassigned after the initial assignment." https://eslint.org/docs/rules/prefer-const This is a rule that helps you spot mistakes while writing code with a let statement. When thinking that you will need to reassign it, eslint will point out you're not actually doing so. This could be because you've forgotten something, assigned the wrong variable, or no longer need to reassign.
2020-04-03 13:44:27 +00:00
"prefer-const": ["warn"],
lint: require camel case variables (#1563) Summary: We’ve had this policy unspoken since the beginning; making it explicit as a lint rule makes it one less thing to think about. The few existing offenders can almost all be changed with no value lost; one is an extern that needs a lint suppression. Test Plan: That Flow and tests still pass suffices. wchargin-branch: lint-camelcase
2020-01-17 16:55:57 +00:00
camelcase: ["error", {properties: "never", allow: ["^_unused_.*"]}],
Enable eslint eqeqeq rule (#1579) The [eqeqeq rule][1] allows us to ban potentially confusing usage of the type-coercing `==` equality operator. I've set it to allow `== null`, and to disallow any other use of `==`. Alongside activating the rule, I've fixed 16 violations. Inspired by [review of #1560][2]. Test plan: `yarn test` passes. [1]: https://eslint.org/docs/rules/eqeqeq [2]: https://github.com/sourcecred/sourcecred/pull/1560#discussion_r368331081
2020-01-20 04:20:15 +00:00
eqeqeq: ["error", "always", {null: "ignore"}],
Fix all lint errors, adding a lint CI step (#175) Test Plan: Run `yarn lint` and `yarn travis` and observe success. Add something that triggers a lint warning, like `const zzz = 3;`; re-run and observe failures. wchargin-branch: lint
2018-04-30 21:52:28 +00:00
"no-unused-vars": [
"warn",
{
argsIgnorePattern: "^_$|^_unused_",
varsIgnorePattern: "^_$|^_unused_",
caughtErrorsIgnorePattern: "^_$|^_unused_",
},
],
Allow `while(true)` loops (#1495) The eslint no-constant-condition rule disallows while(true) loops, since the true is a constant condition. However, I find the allowed alternative (`for (;;)`) less readable, so I am adding the sub-rule that allows constant conditions for loops. Test plan: A followon commit uses a while(true) loop, and, assuming this patch is applied, it does not result in a lint error. Co-authored-by: Robin van Boven <497556+Beanow@users.noreply.github.com>
2019-12-28 23:58:43 +00:00
"no-constant-condition": ["warn", {checkLoops: false}],
Fix all lint errors, adding a lint CI step (#175) Test Plan: Run `yarn lint` and `yarn travis` and observe success. Add something that triggers a lint warning, like `const zzz = 3;`; re-run and observe failures. wchargin-branch: lint
2018-04-30 21:52:28 +00:00
"no-use-before-define": ["off"],
Disable the `no-useless-constructor` lint rule (#308) Summary: In fact, a constructor that only calls `super` is useful: it specifies the API for constructing an object of a given class without needing to traverse its prototype chain. (That constructors are inherited at all is arguably a design flaw.) Test Plan: None. wchargin-branch: yes-useful-constructor
2018-05-28 22:01:28 +00:00
"no-useless-constructor": ["off"],
Update eslint and eslint configuration This commit updates eslint from v4 to v6. In doing so, I've moved off of the create-react-app base eslint config. We were on an old version (v2) and it doesn't make sense to update to v4, as in v4 create-react-app uses typescript. Also, it didn't make sense to stay on create-react-app's v2 config, because then it had unmet peer dependency constraints on old versions of eslint. Instead, I've moved us to use the default rules for eslint, eslint-plugin-react, and eslint-plugin-flowtype. I also made some changes to the codebase to satisfy the new lint rules that came with this change. Test plan: `yarn test` passes.
2019-07-05 17:36:43 +00:00
"no-case-declarations": ["off"],
"react/prop-types": ["off"],
"flowtype/generic-spacing": ["off"],
"flowtype/space-after-type-colon": ["off"],
},
settings: {
react: {
version: "detect",
},
Fix all lint errors, adding a lint CI step (#175) Test Plan: Run `yarn lint` and `yarn travis` and observe success. Add something that triggers a lint warning, like `const zzz = 3;`; re-run and observe failures. wchargin-branch: lint
2018-04-30 21:52:28 +00:00
},
Add BigInt to eslint globals (#1740) Test Plan: grep for global BigInt and make sure there's no longer instances in code files now that we added it to central ESLint Config Paired with @decentralion
2020-04-11 00:54:43 +00:00
globals: {
BigInt: "readonly",
},
Fix all lint errors, adding a lint CI step (#175) Test Plan: Run `yarn lint` and `yarn travis` and observe success. Add something that triggers a lint warning, like `const zzz = 3;`; re-run and observe failures. wchargin-branch: lint
2018-04-30 21:52:28 +00:00
};