@metamask/eslint-config
This package provides MetaMask's ESLint configuration as an extensible shared config.
Usage
We export four ESLint configurations.
Base config
Our default export contains a base set of ESLint rules for ES6+:
yarn add --dev \
eslint@^6.8.0 \
eslint-plugin-import@^2.20.1 \
@metamask/eslint-config@^3.0.0
List @metamask/eslint-config
to your ESLint config via extends
:
module.exports = {
extends: [
'@metamask/eslint-config',
],
}
Node.js
An additional config that supports Node.js-specific environments:
module.exports = {
extends: [
'@metamask/eslint-config',
'@metamask/eslint-config/config/nodejs',
],
}
To lint the .eslintrc.js
file itself, you will need to add this config in addition to the base config.
Jest
An additional config that adds support for Jest:
yarn add --dev \
eslint@^6.8.0 \
eslint-plugin-import@^2.20.1 \
eslint-plugin-jest@^23.6.0 \
@metamask/eslint-config@^3.0.0
module.exports = {
root: true,
extends: [
'@metamask/eslint-config',
'@metamask/eslint-config/config/jest',
],
}
Mocha
An additional config that adds support for Mocha:
yarn add --dev \
eslint@^6.8.0 \
eslint-plugin-import@^2.20.1 \
eslint-plugin-mocha@^6.2.2 \
@metamask/eslint-config@^3.0.0
module.exports = {
root: true,
extends: [
'@metamask/eslint-config',
'@metamask/eslint-config/config/mocha',
],
}
If your project has prefer-arrow-callback
you will need to disable that and replace it with mocha/prefer-arrow-callback
.
TypeScript
An additional config that adds support for TypeScript:
yarn add --dev \
eslint@^6.8.0 \
eslint-plugin-import@^2.20.1 \
@typescript-eslint/eslint-plugin@^2.20.0 \
@typescript-eslint/parser@^2.17.0 \
@metamask/eslint-config@^3.0.0
module.exports = {
root: true,
extends: [
'@metamask/eslint-config',
'@metamask/eslint-config/config/typescript',
],
overrides: [{
files: [
'.eslintrc.js',
],
parserOptions: {
sourceType: 'script',
},
}],
};
Release & Publishing
The project follows the same release process as the other libraries in the MetaMask organization:
- Create a release branch
- For a typical release, this would be based on
master
- To update an older maintained major version, base the release branch on the major version branch (e.g.
1.x
)
- Update the changelog
- Update version in package.json file (e.g.
yarn version --minor --no-git-tag-version
) - Create a pull request targeting the base branch (e.g. master or 1.x)
- Code review and QA
- Once approved, the PR is squashed & merged
- The commit on the base branch is tagged
- The tag can be published as needed