1e494f3004
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. |
||
|---|---|---|
| .. | ||
| transforms | ||
| display.js | ||
| etc.js | ||
| index.js | ||
| manifest.js | ||
| README.md | ||
| sass-compiler.js | ||
| scripts.js | ||
| static.js | ||
| styles.js | ||
| task.js | ||
| utils.js | ||
The MetaMask Build System
tl;dr
yarn distfor prod,yarn startfor local development
This directory contains the MetaMask build system, which is used to build the MetaMask Extension such that it can be used in a supported browser.
From the repository root, the build system entry file is located at ./development/build/index.js.
Several package scripts invoke the build system.
For example, yarn start creates a watched development build, and yarn dist creates a production build.
Some of these scripts applies lavamoat to the build system, and some do not.
For local development, building without lavamoat is faster and therefore preferable.
The build system is not a full-featured CLI, but rather a script that expects some command line arguments and environment variables. For instructions regarding environment variables, see the main repository readme.
Generally speaking, the build system consists of gulp tasks that either manipulate static assets or bundle source files using Browserify.
Production-ready zip files are written to the ./builds directory, while "unpacked" extension builds
are written to the ./dist directory.
Our JavaScript source files are transformed using Babel, specifically using
the babelify Browserify transform.
Source file bundling tasks are implemented in the ./development/build/scripts.js.
Locally implemented Browserify transforms, some of which affect how we write JavaScript, are listed and documented here.
Usage
Usage: yarn build <entry-task> [options]
Commands:
yarn build prod Create an optimized build for production environments.
yarn build dev Create an unoptimized, live-reloaded build for local
development.
yarn build test Create an optimized build for running e2e tests.
yarn build testDev Create an unoptimized, live-reloaded build for running
e2e tests.
Options:
--build-type The "type" of build to create. One of: "beta", "main"
[string] [default: "main"]
--lint-fence-files Whether files with code fences should be linted after
fences have been removed by the code fencing transform.
The build will fail if linting fails.
Defaults to `false` if the entry task is `dev` or
`testDev`, and `true` otherwise.
[boolean] [default: <varies>]
--lockdown Whether to include SES lockdown files in the extension
bundle. Setting this to `false` is useful e.g. when
linking dependencies that are incompatible with lockdown.
[boolean] [default: true]
--policy-only Stops the build after generating the LavaMoat policy,
skipping any writes to disk.
[boolean] [deafult: false]
--skip-stats Whether to refrain from logging build progress. Mostly
used internally.
[boolean] [default: false]