a2d3d942ec
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.
|
||
|---|---|---|
| .. | ||
| 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>]
--omit-lockdown Whether to omit SES lockdown files from the extension
bundle. Useful when linking dependencies that are
incompatible with lockdown.
[boolean] [default: false]
--skip-stats Whether to refrain from logging build progress. Mostly
used internally.
[boolean] [default: false]