m/metamask-extension
1
0
Fork 0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-10-22 03:12:42 +02:00
Code
9cf358a82a
metamask-extension/.eslintrc.js

349 lines
11 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');
Exclude files from builds by build type (#12521) This PR enables the exclusion of JavaScript and JSON source by `buildType`, and enables the running of `eslint` under LavaMoat. 80-90% of the changes in this PR are `.patch` files and LavaMoat policy additions. The file exclusion is designed to work in conjunction with our code fencing. If you forget to fence an import statement of an excluded file, the application will now error on boot. **This PR commits us to a particular naming convention for files intended only for certain builds.** Continue reading for details. ### Code Fencing and ESLint When a file is modified by the code fencing transform, we run ESLint on it to ensure that we fail early for syntax-related issues. This PR adds the first code fences that will be actually be removed in production builds. As a consequence, this was also the first time we attempted to run ESLint under LavaMoat. Making that work required a lot of manual labor because of ESLint's use of dynamic imports, but the manual changes necessary were ultimately quite minor. ### File Exclusion For all builds, any file in `app/`, `shared/` or `ui/` in a sub-directory matching `**/${otherBuildType}/**` (where `otherBuildType` is any build type except `main`) will be added to the list of excluded files, regardless of its file extension. For example, if we want to add one or more pages to the UI settings in Flask, we'd create the folder `ui/pages/settings/flask`, add any necessary files or sub-folders there, and fence the import statements for anything in that folder. If we wanted the same thing for Beta, we would name the directory `ui/pages/settings/beta`. As it happens, we already organize some of our source files in this way, namely the logo JSON for Beta and Flask builds. See `ui/helpers/utils/build-types.js` to see how this works in practice. Because the list of ignored filed is only passed to `browserify.exclude()`, any files not bundled by `browserify` will be ignored. For our purposes, this is mostly relevant for `.scss`. Since we don't have anything like code fencing for SCSS, we'll have to consider how to handle our styles separately.
2021-11-02 04:20:31 +01:00
const { version: reactVersion } = require('react/package.json');
Use shared MetaMask ESLint config (#7882)
2020-01-22 15:37:19 +01:00
module.exports = {
Update ESLint rules for test suite (#8023) * Use @metamask/eslint-config@1.1.0 * Use eslint-plugin-mocha@6.2.2 * Mark root ESLint config as root * Update Mocha ESLint rules with shared ESLint config
2020-02-11 17:51:13 +01:00
root: true,
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
// Ignore files which are also in .prettierignore
Move ESLint ignore patterns into config (#9392)
2020-09-10 19:05:29 +02:00
ignorePatterns: [
'app/vendor/**',
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
'builds/**/*',
'development/chromereload.js',
Adding artifacts (#15145)
2022-07-20 17:33:16 +02:00
'development/charts/**',
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2022-08-09 22:16:08 +02:00
'development/ts-migration-dashboard/build/**',
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
2022-03-21 19:54:47 +01:00
'dist/**/*',
'node_modules/**/*',
Move ESLint ignore patterns into config (#9392)
2020-09-10 19:05:29 +02:00
],
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
overrides: [
/**
* == Modules ==
*
* The first two sections here, which cover module syntax, are mutually
* exclusive: the set of files covered between them may NOT overlap. This is
* because we do not allow a file to use two different styles for specifying
* imports and exports (however theoretically possible it may be).
*/
Move ESLint ignore patterns into config (#9392)
2020-09-10 19:05:29 +02:00
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
{
/**
* Modules (CommonJS module syntax)
*
* This is code that uses `require()` and `module.exports` to import and
* export other modules.
*/
files: [
'.eslintrc.js',
'.eslintrc.*.js',
'.mocharc.js',
'*.config.js',
'development/**/*.js',
'test/e2e/**/*.js',
'test/helpers/*.js',
'test/lib/wait-until-called.js',
],
extends: [
path.resolve(__dirname, '.eslintrc.base.js'),
path.resolve(__dirname, '.eslintrc.node.js'),
path.resolve(__dirname, '.eslintrc.babel.js'),
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
2022-03-21 19:54:47 +01:00
path.resolve(__dirname, '.eslintrc.typescript-compat.js'),
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
],
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
2022-03-21 19:54:47 +01:00
settings: {
'import/resolver': {
// When determining the location of a `require()` call, use Node's
// resolution algorithm, then fall back to TypeScript's. This allows
// TypeScript files (which Node's algorithm doesn't recognize) to be
// imported from JavaScript files, while also preventing issues when
// using packages like `prop-types` (where we would otherwise get "No
// default export found in imported module 'prop-types'" from
// TypeScript because imports work differently there).
node: {},
typescript: {
// Always try to resolve types under `<root>/@types` directory even
// it doesn't contain any source code, like `@types/unist`
alwaysTryTypes: true,
},
},
},
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
},
/**
* Modules (ES module syntax)
*
* This is code that explicitly uses `import`/`export` instead of
* `require`/`module.exports`.
*/
{
files: [
'app/**/*.js',
'shared/**/*.js',
'ui/**/*.js',
'**/*.test.js',
'test/lib/**/*.js',
'test/mocks/**/*.js',
'test/jest/**/*.js',
'test/stub/**/*.js',
'test/unit-global/**/*.js',
],
// TODO: Convert these files to modern JS
excludedFiles: ['test/lib/wait-until-called.js'],
extends: [
path.resolve(__dirname, '.eslintrc.base.js'),
path.resolve(__dirname, '.eslintrc.node.js'),
path.resolve(__dirname, '.eslintrc.babel.js'),
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
2022-03-21 19:54:47 +01:00
path.resolve(__dirname, '.eslintrc.typescript-compat.js'),
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
],
parserOptions: {
sourceType: 'module',
Update ESLint config to v8 (#12886) The ESLint config has been updated to v8. The breaking changes are: * The Prettier rule `quoteProps` has been changed from `consistent` to `as-needed`, meaning that if one key requires quoting, only that key is quoted rather than all keys. * The ESLint rule `no-shadow` has been made more strict. It now prevents globals from being shadowed as well. Most of these changes were applied with `yarn lint:fix`. Only the shadowing changes required manual fixing (shadowing variable names were either replaced with destructuring or renamed). The dependency `globalThis` was added to the list of dynamic dependencies in the build system, where it should have been already. This was causing `depcheck` to fail because the new lint rules required removing the one place where `globalThis` had been erroneously imported previously. A rule requiring a newline between multiline blocks and expressions has been disabled temporarily to make this PR smaller and to avoid introducing conflicts with other PRs.
2021-12-09 20:06:24 +01:00
},
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
2022-03-21 19:54:47 +01:00
settings: {
'import/resolver': {
// When determining the location of an `import`, use Node's resolution
// algorithm, then fall back to TypeScript's. This allows TypeScript
// files (which Node's algorithm doesn't recognize) to be imported
// from JavaScript files, while also preventing issues when using
// packages like `prop-types` (where we would otherwise get "No
// default export found in imported module 'prop-types'" from
// TypeScript because imports work differently there).
node: {},
typescript: {
// Always try to resolve types under `<root>/@types` directory even
// it doesn't contain any source code, like `@types/unist`
alwaysTryTypes: true,
},
},
},
},
/**
* TypeScript files
*/
{
files: ['*.{ts,tsx}'],
extends: [
path.resolve(__dirname, '.eslintrc.base.js'),
'@metamask/eslint-config-typescript',
path.resolve(__dirname, '.eslintrc.typescript-compat.js'),
],
rules: {
// Turn these off, as it's recommended by typescript-eslint.
// See: <https://typescript-eslint.io/docs/linting/troubleshooting#eslint-plugin-import>
'import/named': 'off',
'import/namespace': 'off',
'import/default': 'off',
'import/no-named-as-default-member': 'off',
// Disabled due to incompatibility with Record<string, unknown>.
// See: <https://github.com/Microsoft/TypeScript/issues/15300#issuecomment-702872440>
'@typescript-eslint/consistent-type-definitions': 'off',
// Modified to include the 'ignoreRestSiblings' option.
// TODO: Migrate this rule change back into `@metamask/eslint-config`
'@typescript-eslint/no-unused-vars': [
'error',
{
vars: 'all',
args: 'all',
argsIgnorePattern: '[_]+',
ignoreRestSiblings: true,
},
],
},
settings: {
'import/resolver': {
// When determining the location of an `import`, prefer TypeScript's
// resolution algorithm. Note that due to how we've configured
// TypeScript in `tsconfig.json`, we are able to import JavaScript
// files from TypeScript files.
typescript: {
// Always try to resolve types under `<root>/@types` directory even
// it doesn't contain any source code, like `@types/unist`
alwaysTryTypes: true,
},
},
},
},
{
files: ['*.d.ts'],
parserOptions: {
sourceType: 'script',
},
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
},
Update ESLint config to v8 (#12886) The ESLint config has been updated to v8. The breaking changes are: * The Prettier rule `quoteProps` has been changed from `consistent` to `as-needed`, meaning that if one key requires quoting, only that key is quoted rather than all keys. * The ESLint rule `no-shadow` has been made more strict. It now prevents globals from being shadowed as well. Most of these changes were applied with `yarn lint:fix`. Only the shadowing changes required manual fixing (shadowing variable names were either replaced with destructuring or renamed). The dependency `globalThis` was added to the list of dynamic dependencies in the build system, where it should have been already. This was causing `depcheck` to fail because the new lint rules required removing the one place where `globalThis` had been erroneously imported previously. A rule requiring a newline between multiline blocks and expressions has been disabled temporarily to make this PR smaller and to avoid introducing conflicts with other PRs.
2021-12-09 20:06:24 +01:00
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
/**
* == Everything else ==
*
* The sections from here on out may overlap with each other in various
* ways depending on their function.
*/
/**
* React-specific code
*
* Code in this category contains JSX and hence needs to be run through the
* React plugin.
*/
[RFC] add prettier to eslint (#8595)
2020-11-03 00:41:28 +01:00
{
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
files: [
'test/lib/render-helpers.js',
'test/jest/rendering.js',
'ui/**/*.js',
],
only applies rules to the appropriate files (#10788)
2021-04-01 20:44:31 +02:00
extends: ['plugin:react/recommended', 'plugin:react-hooks/recommended'],
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
parserOptions: {
ecmaFeatures: {
jsx: true,
},
},
plugins: ['react'],
only applies rules to the appropriate files (#10788)
2021-04-01 20:44:31 +02:00
rules: {
'react/no-unused-prop-types': 'error',
'react/no-unused-state': 'error',
'react/jsx-boolean-value': 'error',
'react/jsx-curly-brace-presence': [
'error',
{ props: 'never', children: 'never' },
],
'react/no-deprecated': 'error',
'react/default-props-match-prop-types': 'error',
'react/jsx-no-duplicate-props': 'error',
},
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
settings: {
react: {
// If this is set to 'detect', ESLint will import React in order to
// find its version. Because we run ESLint in the build system under
// LavaMoat, this means that detecting the React version requires a
// LavaMoat policy for all of React, in the build system. That's a
// no-go, so we grab it from React's package.json.
version: reactVersion,
},
[RFC] add prettier to eslint (#8595)
2020-11-03 00:41:28 +01:00
},
Fix global-require issues (#8999)
2020-07-18 01:36:29 +02:00
},
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
/**
* Mocha tests
*
* These are files that make use of globals and syntax introduced by the
* Mocha library.
*/
[RFC] add prettier to eslint (#8595)
2020-11-03 00:41:28 +01:00
{
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
files: [
'**/*.test.js',
'test/lib/wait-until-called.js',
'test/e2e/**/*.spec.js',
],
use jest for testing shared (#11334)
2021-06-24 21:52:29 +02:00
excludedFiles: [
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
'app/scripts/controllers/network/**/*.test.js',
'app/scripts/controllers/permissions/**/*.test.js',
Permission System 2.0 (#12243) # Permission System 2.0 ## Background This PR migrates the extension permission system to [the new `PermissionController`](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions). The original permission system, based on [`rpc-cap`](https://github.com/MetaMask/rpc-cap), introduced [`ZCAP-LD`](https://w3c-ccg.github.io/zcap-ld/)-like permissions to our JSON-RPC stack. We used it to [implement](https://github.com/MetaMask/metamask-extension/pull/7004) what we called "LoginPerSite" in [version 7.7.0](https://github.com/MetaMask/metamask-extension/releases/tag/v7.7.0) of the extension, which enabled the user to choose which accounts, if any, should be exposed to each dapp. While that was a worthwhile feature in and of itself, we wanted a permission _system_ in order to enable everything we are going to with Snaps. Unfortunately, the original permission system was difficult to use, and necessitated the creation of the original `PermissionsController` (note the "s"), which was more or less a wrapper for `rpc-cap`. With this PR, we shake off the yoke of the original permission system, in favor of the modular, self-contained, ergonomic, and more mature permission system 2.0. Note that [the `PermissionController` readme](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions/README.md) explains how the new permission system works. The `PermissionController` and `SubjectMetadataController` are currently shipped via `@metamask/snap-controllers`. This is a temporary state of affairs, and we'll move them to `@metamask/controllers` once they've landed in prod. ## Changes in Detail First, the changes in this PR are not as big as they seem. Roughly half of the additions in this PR are fixtures in the test for the new migration (number 68), and a significant portion of the remaining ~2500 lines are due to find-and-replace changes in other test fixtures and UI files. - The extension `PermissionsController` has been deleted, and completely replaced with the new `PermissionController` from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers). - The original `PermissionsController` "domain metadata" functionality is now managed by the new `SubjectMetadataController`, also from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers). - The permission activity and history log controller has been renamed `PermissionLogController` and has its own top-level state key, but is otherwise functionally equivalent to the existing implementation. - Migration number 68 has been added to account for the new state changes. - The tests in `app/scripts/controllers/permissions` have been migrated from `mocha` to `jest`. Reviewers should focus their attention on the following files: - `app/scripts/` - `metamask-controller.js` - This is where most of the integration work for the new `PermissionController` occurs. Some functions that were internal to the original controller were moved here. - `controllers/permissions/` - `selectors.js` - These selectors are for `ControllerMessenger` selector subscriptions. The actual subscriptions occur in `metamask-controller.js`. See the `ControllerMessenger` implementation for details. - `specifications.js` - The caveat and permission specifications are required by the new `PermissionController`, and are used to specify the `eth_accounts` permission and its JSON-RPC method implementation. See the `PermissionController` readme for details. - `migrations/068.js` - The new state should be cross-referenced with the controllers that manage it. The accompanying tests should also be thoroughly reviewed. Some files may appear new but have just moved and/or been renamed: - `app/scripts/lib/rpc-method-middleware/handlers/request-accounts.js` - This was previously implemented in `controllers/permissions/permissionsMethodMiddleware.js`. - `test/mocks/permissions.js` - A truncated version of `test/mocks/permission-controller.js`. Co-authored-by: Mark Stacey <markjstacey@gmail.com>
2021-12-07 04:16:49 +01:00
'app/scripts/lib/**/*.test.js',
Jestify migrations/ (#12106) * Jestify migrations/ * Lint exclude migrations from mocha config, and add inclusion to jest config * Add migration tests to jest config * Exclude/ignore migration tests * Set process.env.IN_TEST to true when running tests locally
2021-09-21 18:28:13 +02:00
'app/scripts/migrations/*.test.js',
Normalize extension verison to SemVer (#12254) The extension version used throughout the wallet is now normalized to a SemVer-compliant version that matches the version used in `package.json`. We use this version for display on the "About" page, and we attach it to all error reports and metric events, so it's important that we format it consistently so that we can correlate events on the same version across different browsers. This normalization step is necessary because Firefox and Chrome both have different requirements for the extension version, and neither is SemVer-compliant.
2021-10-14 23:20:14 +02:00
'app/scripts/platforms/*.test.js',
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
'development/**/*.test.js',
'shared/**/*.test.js',
'ui/**/*.test.js',
'ui/__mocks__/*.js',
use jest for testing shared (#11334)
2021-06-24 21:52:29 +02:00
],
@metamask/eslint-config*@6.0.0 (#10858) * @metamask/eslint-config*@6.0.0 * Minor eslintrc reorg
2021-04-08 23:34:55 +02:00
extends: ['@metamask/eslint-config-mocha'],
[RFC] add prettier to eslint (#8595)
2020-11-03 00:41:28 +01:00
rules: {
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
// In Mocha tests, it is common to use `this` to store values or do
// things like force the test to fail.
'@babel/no-invalid-this': 'off',
only applies rules to the appropriate files (#10788)
2021-04-01 20:44:31 +02:00
'mocha/no-setup-in-describe': 'off',
eslint perf improvement (#10775)
2021-03-31 17:19:20 +02:00
},
},
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
/**
* Jest tests
*
* These are files that make use of globals and syntax introduced by the
* Jest library.
*/
Increase Jest unit test coverage for the Swaps feature to ~25% (#10900) * Swaps: Show a network name dynamically in a tooltip * Replace “Ethereum” with “$1”, change “Test” to “Testnet” * Replace 이더리움 with $1 * Translate network names, use ‘Ethereum’ by default if a translation is not available yet * Reorder messages to resolve ESLint issues * Add a snapshot test for the FeeCard component, increase Jest threshold * Enable snapshot testing into external .snap files in ESLint * Add the “networkNameEthereum” key in ko/messages.json, remove default “Ethereum” value * Throw an error if chain ID is not supported by the Swaps feature * Use string literals when calling the `t` fn, * Watch Jest tests silently (no React warnings in terminal, only errors) * Add @testing-library/jest-dom, import it before running Jest tests * Add snapshot testing of Swaps’ React components for happy paths, increase minimum threshold for Jest * Add the test/jest folder for Jest setup and shared functions, use it in Swaps Jest tests * Fix ESLint issues, update linting config * Enable ESLint for .snap files (Jest snapshots), throw an error if a snapshot is bigger than 50 lines * Don’t run lint:fix for .snap files * Move `createProps` outside of `describe` blocks, move store creation inside tests * Use translations instead of keys, update a rendering function to load translations * Make sure all Jest snapshots are shorter than 50 lines (default limit) * Add / update props for Swaps tests * Fix React warnings when running tests for Swaps
2021-04-21 21:34:35 +02:00
{
Add build-time code exclusion using code fencing (#12060) This PR adds build-time code exclusion by means of code fencing. For details, please see the README in `./development/build/transforms`. Note that linting of transformed files as a form of validation is added in a follow-up, #12075. Hopefully exhaustive tests are added to ensure that the transform works according to its specification. Since these tests are Node-only, they required their own Jest config. The recommended way to work with multiple Jest configs is using the `projects` field in the Jest config, however [that feature breaks coverage collection](https://github.com/facebook/jest/issues/9628). That being the case, I had to set up two separate Jest configs. In order to get both test suites to run in parallel, Jest is now invoked via a script, `./test/run-jest.sh`. By way of example, this build system feature allows us to add fences like this: ```javascript this.store.updateStructure({ ..., GasFeeController: this.gasFeeController, TokenListController: this.tokenListController, ///: BEGIN:ONLY_INCLUDE_IN(beta) PluginController: this.pluginController, ///: END:ONLY_INCLUDE_IN }); ``` Which at build time are transformed to the following if the build type is not `beta`: ```javascript this.store.updateStructure({ ..., GasFeeController: this.gasFeeController, TokenListController: this.tokenListController, }); ``` Co-authored-by: Mark Stacey <markjstacey@gmail.com>
2021-09-14 19:00:04 +02:00
files: [
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
'**/__snapshots__/*.snap',
'app/scripts/controllers/network/**/*.test.js',
'app/scripts/controllers/permissions/**/*.test.js',
Permission System 2.0 (#12243) # Permission System 2.0 ## Background This PR migrates the extension permission system to [the new `PermissionController`](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions). The original permission system, based on [`rpc-cap`](https://github.com/MetaMask/rpc-cap), introduced [`ZCAP-LD`](https://w3c-ccg.github.io/zcap-ld/)-like permissions to our JSON-RPC stack. We used it to [implement](https://github.com/MetaMask/metamask-extension/pull/7004) what we called "LoginPerSite" in [version 7.7.0](https://github.com/MetaMask/metamask-extension/releases/tag/v7.7.0) of the extension, which enabled the user to choose which accounts, if any, should be exposed to each dapp. While that was a worthwhile feature in and of itself, we wanted a permission _system_ in order to enable everything we are going to with Snaps. Unfortunately, the original permission system was difficult to use, and necessitated the creation of the original `PermissionsController` (note the "s"), which was more or less a wrapper for `rpc-cap`. With this PR, we shake off the yoke of the original permission system, in favor of the modular, self-contained, ergonomic, and more mature permission system 2.0. Note that [the `PermissionController` readme](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions/README.md) explains how the new permission system works. The `PermissionController` and `SubjectMetadataController` are currently shipped via `@metamask/snap-controllers`. This is a temporary state of affairs, and we'll move them to `@metamask/controllers` once they've landed in prod. ## Changes in Detail First, the changes in this PR are not as big as they seem. Roughly half of the additions in this PR are fixtures in the test for the new migration (number 68), and a significant portion of the remaining ~2500 lines are due to find-and-replace changes in other test fixtures and UI files. - The extension `PermissionsController` has been deleted, and completely replaced with the new `PermissionController` from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers). - The original `PermissionsController` "domain metadata" functionality is now managed by the new `SubjectMetadataController`, also from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers). - The permission activity and history log controller has been renamed `PermissionLogController` and has its own top-level state key, but is otherwise functionally equivalent to the existing implementation. - Migration number 68 has been added to account for the new state changes. - The tests in `app/scripts/controllers/permissions` have been migrated from `mocha` to `jest`. Reviewers should focus their attention on the following files: - `app/scripts/` - `metamask-controller.js` - This is where most of the integration work for the new `PermissionController` occurs. Some functions that were internal to the original controller were moved here. - `controllers/permissions/` - `selectors.js` - These selectors are for `ControllerMessenger` selector subscriptions. The actual subscriptions occur in `metamask-controller.js`. See the `ControllerMessenger` implementation for details. - `specifications.js` - The caveat and permission specifications are required by the new `PermissionController`, and are used to specify the `eth_accounts` permission and its JSON-RPC method implementation. See the `PermissionController` readme for details. - `migrations/068.js` - The new state should be cross-referenced with the controllers that manage it. The accompanying tests should also be thoroughly reviewed. Some files may appear new but have just moved and/or been renamed: - `app/scripts/lib/rpc-method-middleware/handlers/request-accounts.js` - This was previously implemented in `controllers/permissions/permissionsMethodMiddleware.js`. - `test/mocks/permissions.js` - A truncated version of `test/mocks/permission-controller.js`. Co-authored-by: Mark Stacey <markjstacey@gmail.com>
2021-12-07 04:16:49 +01:00
'app/scripts/lib/**/*.test.js',
Jestify migrations/ (#12106) * Jestify migrations/ * Lint exclude migrations from mocha config, and add inclusion to jest config * Add migration tests to jest config * Exclude/ignore migration tests * Set process.env.IN_TEST to true when running tests locally
2021-09-21 18:28:13 +02:00
'app/scripts/migrations/*.test.js',
Normalize extension verison to SemVer (#12254) The extension version used throughout the wallet is now normalized to a SemVer-compliant version that matches the version used in `package.json`. We use this version for display on the "About" page, and we attach it to all error reports and metric events, so it's important that we format it consistently so that we can correlate events on the same version across different browsers. This normalization step is necessary because Firefox and Chrome both have different requirements for the extension version, and neither is SemVer-compliant.
2021-10-14 23:20:14 +02:00
'app/scripts/platforms/*.test.js',
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
'development/**/*.test.js',
'shared/**/*.test.js',
'test/jest/*.js',
'test/helpers/*.js',
'ui/**/*.test.js',
'ui/__mocks__/*.js',
Add build-time code exclusion using code fencing (#12060) This PR adds build-time code exclusion by means of code fencing. For details, please see the README in `./development/build/transforms`. Note that linting of transformed files as a form of validation is added in a follow-up, #12075. Hopefully exhaustive tests are added to ensure that the transform works according to its specification. Since these tests are Node-only, they required their own Jest config. The recommended way to work with multiple Jest configs is using the `projects` field in the Jest config, however [that feature breaks coverage collection](https://github.com/facebook/jest/issues/9628). That being the case, I had to set up two separate Jest configs. In order to get both test suites to run in parallel, Jest is now invoked via a script, `./test/run-jest.sh`. By way of example, this build system feature allows us to add fences like this: ```javascript this.store.updateStructure({ ..., GasFeeController: this.gasFeeController, TokenListController: this.tokenListController, ///: BEGIN:ONLY_INCLUDE_IN(beta) PluginController: this.pluginController, ///: END:ONLY_INCLUDE_IN }); ``` Which at build time are transformed to the following if the build type is not `beta`: ```javascript this.store.updateStructure({ ..., GasFeeController: this.gasFeeController, TokenListController: this.tokenListController, }); ``` Co-authored-by: Mark Stacey <markjstacey@gmail.com>
2021-09-14 19:00:04 +02:00
],
Jest config (#10855) * Setup jest config * Adjust test for jest. * Adjust lint config * Omit swaps ui folder for unit testing * Omit swaps from test:unit:lax * Add jest.config.js to script files * Restore mocks rather than clearing them. * Update jest config and adjust lint to include subdirs * Convert view-quote-price-difference test to jest * Add jest ci and ci coverage scripts. Add jest unit test to general test command * Add test coverage to ci * Use --ignore flag * Fixup * Add @metamask/eslint-config-jest * Update .eslintrc.js Co-authored-by: Mark Stacey <markjstacey@gmail.com> * Adds jest-coverage/ Co-authored-by: Mark Stacey <markjstacey@gmail.com>
2021-04-09 19:20:32 +02:00
extends: ['@metamask/eslint-config-jest'],
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
parserOptions: {
sourceType: 'module',
},
Swaps: Show a network name dynamically in a tooltip (#10882) * Swaps: Show a network name dynamically in a tooltip * Replace “Ethereum” with “$1”, change “Test” to “Testnet” * Replace 이더리움 with $1 * Translate network names, use ‘Ethereum’ by default if a translation is not available yet * Reorder messages to resolve ESLint issues * Add a snapshot test for the FeeCard component, increase Jest threshold * Enable snapshot testing into external .snap files in ESLint * Add the “networkNameEthereum” key in ko/messages.json, remove default “Ethereum” value * Throw an error if chain ID is not supported by the Swaps feature * Use string literals when calling the `t` fn,
2021-04-16 23:52:32 +02:00
rules: {
Increase Jest unit test coverage for the Swaps feature to ~25% (#10900) * Swaps: Show a network name dynamically in a tooltip * Replace “Ethereum” with “$1”, change “Test” to “Testnet” * Replace 이더리움 with $1 * Translate network names, use ‘Ethereum’ by default if a translation is not available yet * Reorder messages to resolve ESLint issues * Add a snapshot test for the FeeCard component, increase Jest threshold * Enable snapshot testing into external .snap files in ESLint * Add the “networkNameEthereum” key in ko/messages.json, remove default “Ethereum” value * Throw an error if chain ID is not supported by the Swaps feature * Use string literals when calling the `t` fn, * Watch Jest tests silently (no React warnings in terminal, only errors) * Add @testing-library/jest-dom, import it before running Jest tests * Add snapshot testing of Swaps’ React components for happy paths, increase minimum threshold for Jest * Add the test/jest folder for Jest setup and shared functions, use it in Swaps Jest tests * Fix ESLint issues, update linting config * Enable ESLint for .snap files (Jest snapshots), throw an error if a snapshot is bigger than 50 lines * Don’t run lint:fix for .snap files * Move `createProps` outside of `describe` blocks, move store creation inside tests * Use translations instead of keys, update a rendering function to load translations * Make sure all Jest snapshots are shorter than 50 lines (default limit) * Add / update props for Swaps tests * Fix React warnings when running tests for Swaps
2021-04-21 21:34:35 +02:00
'import/unambiguous': 'off',
Increase Jest unit test coverage for the Swaps feature to ~43% (#10934)
2021-04-27 22:16:17 +02:00
'import/named': 'off',
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
'jest/no-large-snapshots': [
'error',
{ maxSize: 50, inlineMaxSize: 50 },
],
'jest/no-restricted-matchers': 'off',
Update Eslint and deps (#15293)
2022-07-26 20:10:51 +02:00
/**
* jest/prefer-to-be is a new rule that was disabled to reduce churn
* when upgrading eslint. It should be considered for use and enabled
* in a future PR if agreeable.
*/
'jest/prefer-to-be': 'off',
/**
* jest/lowercase-name was renamed to jest/prefer-lowercase-title this
* change was made to essentially retain the same state as the original
* eslint-config-jest until it is updated. At which point the following
* two lines can be deleted.
*/
'jest/lowercase-name': 'off',
'jest/prefer-lowercase-title': ['error', { ignore: ['describe'] }],
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
},
},
/**
* Migrations
*/
{
files: ['app/scripts/migrations/*.js', '**/*.stories.js'],
rules: {
'import/no-anonymous-default-export': ['error', { allowObject: true }],
Swaps: Show a network name dynamically in a tooltip (#10882) * Swaps: Show a network name dynamically in a tooltip * Replace “Ethereum” with “$1”, change “Test” to “Testnet” * Replace 이더리움 with $1 * Translate network names, use ‘Ethereum’ by default if a translation is not available yet * Reorder messages to resolve ESLint issues * Add a snapshot test for the FeeCard component, increase Jest threshold * Enable snapshot testing into external .snap files in ESLint * Add the “networkNameEthereum” key in ko/messages.json, remove default “Ethereum” value * Throw an error if chain ID is not supported by the Swaps feature * Use string literals when calling the `t` fn,
2021-04-16 23:52:32 +02:00
},
Jest config (#10855) * Setup jest config * Adjust test for jest. * Adjust lint config * Omit swaps ui folder for unit testing * Omit swaps from test:unit:lax * Add jest.config.js to script files * Restore mocks rather than clearing them. * Update jest config and adjust lint to include subdirs * Convert view-quote-price-difference test to jest * Add jest ci and ci coverage scripts. Add jest unit test to general test command * Add test coverage to ci * Use --ignore flag * Fixup * Add @metamask/eslint-config-jest * Update .eslintrc.js Co-authored-by: Mark Stacey <markjstacey@gmail.com> * Adds jest-coverage/ Co-authored-by: Mark Stacey <markjstacey@gmail.com>
2021-04-09 19:20:32 +02:00
},
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
/**
* Executables and related files
*
* These are files that run in a Node context. They are either designed to
* run as executables (in which case they will have a shebang at the top) or
* are dependencies of executables (in which case they may use
* `process.exit` to exit).
*/
[RFC] add prettier to eslint (#8595)
2020-11-03 00:41:28 +01:00
{
colocate tests in flat structure (#10655)
2021-03-16 22:00:08 +01:00
files: [
'development/**/*.js',
'test/e2e/benchmark.js',
'test/helpers/setup-helper.js',
],
[RFC] add prettier to eslint (#8595)
2020-11-03 00:41:28 +01:00
rules: {
'node/no-process-exit': 'off',
'node/shebang': 'off',
},
Fix no-process-exit issues (#9219) See [`no-process-exit`](https://eslint.org/docs/rules/no-process-exit) for more information. This change enables `no-process-exit` and fixes the issues raised by the rule.
2020-08-13 23:31:40 +02:00
},
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
/**
* Lockdown files
*/
Make all named intrinsics non-modifiable (#11953) This PR makes ~all named intrinsics in all of our JavaScript processes non-modifiable. A named intrinsic is any property specified by the ECMAScript specification that exists on `globalThis` when the JavaScript process starts. We say that a property is non-modifiable if it is non-configurable and non-writable. We make exceptions for properties that meet any of the following criteria: 1. Properties that are non-configurable by the time `lockdown-run.js` is executed are not modified, because they can't be. 2. Properties that have accessor properties (`get` or `set`) are made non-configurable, but their writability cannot be modified, and is therefore left unchanged. It's unclear how many of the named intrinsics this applies to, if any, but it's good defensive programming, regardless.
2021-08-30 23:30:48 +02:00
{
files: [
'app/scripts/lockdown-run.js',
lockdown - breakout making globalThis properties non-writable (#12258) * lockdown - breakout making globalThis properties non-writable into lockdown-more.js * Update app/scripts/lockdown-more.js Co-authored-by: David Walsh <davidwalsh83@gmail.com> * Update app/scripts/lockdown-more.js Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com> Co-authored-by: David Walsh <davidwalsh83@gmail.com> Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
2021-10-01 20:53:12 +02:00
'app/scripts/lockdown-more.js',
Add lockdown e2e test (#12562) This PR adds an e2e test to ensure that the background and UI environments are locked down. It reuses the logic from the `protect-intrinsics.test.js`, and runs in both Chrome and Firefox.
2021-11-03 01:01:01 +01:00
'test/helpers/protect-intrinsics-helpers.js',
Make all named intrinsics non-modifiable (#11953) This PR makes ~all named intrinsics in all of our JavaScript processes non-modifiable. A named intrinsic is any property specified by the ECMAScript specification that exists on `globalThis` when the JavaScript process starts. We say that a property is non-modifiable if it is non-configurable and non-writable. We make exceptions for properties that meet any of the following criteria: 1. Properties that are non-configurable by the time `lockdown-run.js` is executed are not modified, because they can't be. 2. Properties that have accessor properties (`get` or `set`) are made non-configurable, but their writability cannot be modified, and is therefore left unchanged. It's unclear how many of the named intrinsics this applies to, if any, but it's good defensive programming, regardless.
2021-08-30 23:30:48 +02:00
'test/unit-global/protect-intrinsics.test.js',
],
globals: {
harden: 'readonly',
Compartment: 'readonly',
},
},
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
{
files: ['app/scripts/lockdown-run.js', 'app/scripts/lockdown-more.js'],
parserOptions: {
sourceType: 'script',
},
Use eslint-plugin-react@7.18.3 (#8085)
2020-02-24 19:54:35 +01:00
},
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
],
@metamask/eslint config@5.0.0 (#10358) * @metamask/eslint-config@5.0.0 * Update eslintrc and prettierrc * yarn lint:fix
2021-02-04 19:15:23 +01:00
};
Copy Permalink