1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-25 11:28:51 +01:00
metamask-extension/.eslintrc.base.js

80 lines
2.3 KiB
JavaScript
Raw Normal View History

Refactor ESLint config (#13482) We would like to insert TypeScript into the ESLint configuration, and because of the way that the current config is organized, that is not easy to do. Most files are assumed to be files that are suited for running in a browser context. This isn't correct, as we should expect most files to work in a Node context instead. This is because all browser-based files will be run through a transpiler that is able to make use of Node-specific variables anyway. There are a couple of important ways we can categories files which our ESLint config should be capable of handling well: * Is the file a script or a module? In other words, does the file run procedurally or is the file intended to be brought into an existing file? * If the file is a module, does it use the CommonJS syntax (`require()`) or does it use the ES syntax (`import`/`export`)? When we introduce TypeScript, this set of questions will become: * Is the file a script or a module? * If the file is a module, is it a JavaScript module or a TypeScript module? * If the file is a JavaScript module, does it use the CommonJS syntax (`require()`) or does it use the ES syntax (`import`/`export`)? To represent these divisions, this commit removes global rules — so now all of the rules are kept in `overrides` for explicitness — and sets up rules for CommonJS- and ES-module-compatible files that intentionally do not overlap with each other. This way TypeScript (which has its own set of rules independent from JavaScript and therefore shouldn't overlap with the other rules either) can be easily added later. Finally, this commit splits up the ESLint config into separate files and adds documentation to each section. This way sets of rules which are connected to a particular plugin (`jsdoc`, `@babel`, etc.) can be easily understood instead of being obscured.
2022-02-28 18:42:09 +01:00
const path = require('path');
module.exports = {
extends: [
'@metamask/eslint-config',
path.resolve(__dirname, '.eslintrc.jsdoc.js'),
],
globals: {
document: 'readonly',
window: 'readonly',
},
rules: {
'default-param-last': 'off',
'prefer-object-spread': 'error',
'require-atomic-updates': 'off',
// This is the same as our default config, but for the noted exceptions
'spaced-comment': [
'error',
'always',
{
markers: [
'global',
'globals',
'eslint',
'eslint-disable',
'*package',
'!',
',',
// Local additions
'/:', // This is for our code fences
],
exceptions: ['=', '-'],
},
],
'no-invalid-this': 'off',
// TODO: remove this override
'padding-line-between-statements': [
'error',
{
blankLine: 'always',
prev: 'directive',
next: '*',
},
{
blankLine: 'any',
prev: 'directive',
next: 'directive',
},
// Disabled temporarily to reduce conflicts while PR queue is large
// {
// blankLine: 'always',
// prev: ['multiline-block-like', 'multiline-expression'],
// next: ['multiline-block-like', 'multiline-expression'],
// },
],
// It is common to import modules without assigning them to variables in
// a browser context. For instance, we may import polyfills which change
// global variables, or we may import stylesheets.
'import/no-unassigned-import': 'off',
2022-07-26 20:10:51 +02:00
// import/no-named-as-default-member checks if default imports also have
// named exports matching properties used on the default import. Example:
// in confirm-seed-phrase-component.test.js we import sinon from 'sinon'
// and later access sinon.spy. spy is also exported from sinon directly and
// thus triggers the error. Turning this rule off to prevent churn when
// upgrading eslint and dependencies. This rule should be evaluated and
// if agreeable turned on upstream in @metamask/eslint-config
'import/no-named-as-default-member': 'off',
// This is necessary to run eslint on Windows and not get a thousand CRLF errors
'prettier/prettier': ['error', { endOfLine: 'auto' }],
Refactor ESLint config (#13482) We would like to insert TypeScript into the ESLint configuration, and because of the way that the current config is organized, that is not easy to do. Most files are assumed to be files that are suited for running in a browser context. This isn't correct, as we should expect most files to work in a Node context instead. This is because all browser-based files will be run through a transpiler that is able to make use of Node-specific variables anyway. There are a couple of important ways we can categories files which our ESLint config should be capable of handling well: * Is the file a script or a module? In other words, does the file run procedurally or is the file intended to be brought into an existing file? * If the file is a module, does it use the CommonJS syntax (`require()`) or does it use the ES syntax (`import`/`export`)? When we introduce TypeScript, this set of questions will become: * Is the file a script or a module? * If the file is a module, is it a JavaScript module or a TypeScript module? * If the file is a JavaScript module, does it use the CommonJS syntax (`require()`) or does it use the ES syntax (`import`/`export`)? To represent these divisions, this commit removes global rules — so now all of the rules are kept in `overrides` for explicitness — and sets up rules for CommonJS- and ES-module-compatible files that intentionally do not overlap with each other. This way TypeScript (which has its own set of rules independent from JavaScript and therefore shouldn't overlap with the other rules either) can be easily added later. Finally, this commit splits up the ESLint config into separate files and adds documentation to each section. This way sets of rules which are connected to a particular plugin (`jsdoc`, `@babel`, etc.) can be easily understood instead of being obscured.
2022-02-28 18:42:09 +01:00
},
};