|
|
|
const { ESLint } = require('eslint');
|
|
|
|
const eslintrc = require('../../../.eslintrc.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.
3 years ago
|
|
|
eslintrc.overrides.forEach((override) => {
|
|
|
|
const rules = override.rules ?? {};
|
|
|
|
|
|
|
|
// We don't want linting to fail for purely stylistic reasons.
|
|
|
|
rules['prettier/prettier'] = 'off';
|
|
|
|
// Sometimes we use `let` instead of `const` to assign variables depending on
|
|
|
|
// the build type.
|
|
|
|
rules['prefer-const'] = 'off';
|
|
|
|
|
|
|
|
override.rules = rules;
|
|
|
|
});
|
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.
3 years ago
|
|
|
|
|
|
|
// Remove all test-related overrides. We will never lint test files here.
|
|
|
|
eslintrc.overrides = eslintrc.overrides.filter((override) => {
|
|
|
|
return !(
|
|
|
|
(override.extends &&
|
|
|
|
override.extends.find(
|
|
|
|
(configName) =>
|
|
|
|
configName.includes('jest') || configName.includes('mocha'),
|
|
|
|
)) ||
|
|
|
|
(override.plugins &&
|
|
|
|
override.plugins.find((pluginName) => pluginName.includes('jest')))
|
|
|
|
);
|
|
|
|
});
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The singleton ESLint instance.
|
|
|
|
*
|
|
|
|
* @type {ESLint}
|
|
|
|
*/
|
|
|
|
let eslintInstance;
|
|
|
|
|
|
|
|
// We only need a single ESLint instance, and we only initialize it if necessary
|
|
|
|
const initializeESLint = () => {
|
|
|
|
if (!eslintInstance) {
|
|
|
|
eslintInstance = new ESLint({ baseConfig: eslintrc, useEslintrc: false });
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
// Four spaces
|
|
|
|
const TAB = ' ';
|
|
|
|
|
|
|
|
module.exports = {
|
|
|
|
lintTransformedFile,
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Lints a transformed file by invoking ESLint programmatically on the string
|
|
|
|
* file contents. The path to the file must be specified so that the repository
|
|
|
|
* ESLint config can be applied properly.
|
|
|
|
*
|
|
|
|
* An error is thrown if linting produced any errors, or if the file is ignored
|
|
|
|
* by ESLint. Files linted by this function should never be ignored.
|
|
|
|
*
|
|
|
|
* @param {string} content - The file content.
|
|
|
|
* @param {string} filePath - The path to the file.
|
|
|
|
* @returns {Promise<void>} Returns `undefined` or throws an error if linting produced
|
|
|
|
* any errors, or if the linted file is ignored.
|
|
|
|
*/
|
|
|
|
async function lintTransformedFile(content, filePath) {
|
|
|
|
initializeESLint();
|
|
|
|
|
|
|
|
const lintResult = (
|
|
|
|
await eslintInstance.lintText(content, { filePath, warnIgnored: false })
|
|
|
|
)[0];
|
|
|
|
|
|
|
|
// This indicates that the file is ignored, which should never be the case for
|
|
|
|
// a transformed file.
|
|
|
|
if (lintResult === undefined) {
|
|
|
|
throw new Error(
|
|
|
|
`MetaMask build: Transformed file "${filePath}" appears to be ignored by ESLint.`,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is the success case
|
|
|
|
if (lintResult.errorCount === 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Errors are stored in the messages array, and their "severity" is 2
|
|
|
|
const errorsString = lintResult.messages
|
|
|
|
.filter(({ severity }) => severity === 2)
|
|
|
|
.reduce((allErrors, { message, ruleId }) => {
|
|
|
|
return allErrors.concat(`${TAB}${ruleId}\n${TAB}${message}\n\n`);
|
|
|
|
}, '');
|
|
|
|
|
|
|
|
throw new Error(
|
|
|
|
`MetaMask build: Lint errors encountered for transformed file "${filePath}":\n\n${errorsString}`,
|
|
|
|
);
|
|
|
|
}
|