|
|
|
const { callbackify } = require('util');
|
|
|
|
const path = require('path');
|
|
|
|
const { writeFileSync, readFileSync } = require('fs');
|
|
|
|
const EventEmitter = require('events');
|
|
|
|
const gulp = require('gulp');
|
|
|
|
const watch = require('gulp-watch');
|
|
|
|
const Vinyl = require('vinyl');
|
|
|
|
const source = require('vinyl-source-stream');
|
|
|
|
const buffer = require('vinyl-buffer');
|
|
|
|
const log = require('fancy-log');
|
|
|
|
const browserify = require('browserify');
|
|
|
|
const watchify = require('watchify');
|
|
|
|
const babelify = require('babelify');
|
|
|
|
const brfs = require('brfs');
|
|
|
|
const envify = require('loose-envify/custom');
|
|
|
|
const sourcemaps = require('gulp-sourcemaps');
|
|
|
|
const applySourceMap = require('vinyl-sourcemaps-apply');
|
|
|
|
const pify = require('pify');
|
|
|
|
const through = require('through2');
|
|
|
|
const endOfStream = pify(require('end-of-stream'));
|
|
|
|
const labeledStreamSplicer = require('labeled-stream-splicer').obj;
|
|
|
|
const wrapInStream = require('pumpify').obj;
|
|
|
|
const Sqrl = require('squirrelly');
|
|
|
|
const lavapack = require('@lavamoat/lavapack');
|
|
|
|
const lavamoatBrowserify = require('lavamoat-browserify');
|
|
|
|
const terser = require('terser');
|
|
|
|
|
|
|
|
const bifyModuleGroups = require('bify-module-groups');
|
|
|
|
|
|
|
|
const { streamFlatMap } = require('../stream-flat-map');
|
|
|
|
const { BuildType } = require('../lib/build-type');
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
const { BUILD_TARGETS, ENVIRONMENT } = require('./constants');
|
|
|
|
const { getConfig, getProductionConfig } = require('./config');
|
|
|
|
const {
|
|
|
|
isDevBuild,
|
|
|
|
isTestBuild,
|
|
|
|
getEnvironment,
|
|
|
|
logError,
|
|
|
|
} = require('./utils');
|
|
|
|
|
|
|
|
const {
|
|
|
|
createTask,
|
|
|
|
composeParallel,
|
|
|
|
composeSeries,
|
|
|
|
runInChildProcess,
|
|
|
|
} = require('./task');
|
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>
3 years ago
|
|
|
const {
|
|
|
|
createRemoveFencedCodeTransform,
|
|
|
|
} = require('./transforms/remove-fenced-code');
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the appropriate Infura project ID.
|
|
|
|
*
|
|
|
|
* @param {object} options - The Infura project ID options.
|
|
|
|
* @param {BuildType} options.buildType - The current build type.
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
* @param {object} options.config - The environment variable configuration.
|
|
|
|
* @param {ENVIRONMENT[keyof ENVIRONMENT]} options.environment - The build environment.
|
|
|
|
* @param {boolean} options.testing - Whether this is a test build or not.
|
|
|
|
* @returns {string} The Infura project ID.
|
|
|
|
*/
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
function getInfuraProjectId({ buildType, config, environment, testing }) {
|
|
|
|
if (testing) {
|
|
|
|
return '00000000000000000000000000000000';
|
|
|
|
} else if (environment !== ENVIRONMENT.PRODUCTION) {
|
|
|
|
// Skip validation because this is unset on PRs from forks.
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.INFURA_PROJECT_ID;
|
|
|
|
} else if (buildType === BuildType.main) {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.INFURA_PROD_PROJECT_ID;
|
|
|
|
} else if (buildType === BuildType.beta) {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.INFURA_BETA_PROJECT_ID;
|
|
|
|
} else if (buildType === BuildType.flask) {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.INFURA_FLASK_PROJECT_ID;
|
|
|
|
}
|
|
|
|
throw new Error(`Invalid build type: '${buildType}'`);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the appropriate Segment write key.
|
|
|
|
*
|
|
|
|
* @param {object} options - The Segment write key options.
|
|
|
|
* @param {BuildType} options.buildType - The current build type.
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
* @param {object} options.config - The environment variable configuration.
|
|
|
|
* @param {keyof ENVIRONMENT} options.environment - The current build environment.
|
|
|
|
* @returns {string} The Segment write key.
|
|
|
|
*/
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
function getSegmentWriteKey({ buildType, config, environment }) {
|
|
|
|
if (environment !== ENVIRONMENT.PRODUCTION) {
|
|
|
|
// Skip validation because this is unset on PRs from forks, and isn't necessary for development builds.
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.SEGMENT_WRITE_KEY;
|
|
|
|
} else if (buildType === BuildType.main) {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.SEGMENT_PROD_WRITE_KEY;
|
|
|
|
} else if (buildType === BuildType.beta) {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.SEGMENT_BETA_WRITE_KEY;
|
|
|
|
} else if (buildType === BuildType.flask) {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
return config.SEGMENT_FLASK_WRITE_KEY;
|
|
|
|
}
|
|
|
|
throw new Error(`Invalid build type: '${buildType}'`);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the URL for the phishing warning page, if it has been set.
|
|
|
|
*
|
|
|
|
* @param {object} options - The phishing warning page options.
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
* @param {object} options.config - The environment variable configuration.
|
|
|
|
* @param {boolean} options.testing - Whether this is a test build or not.
|
|
|
|
* @returns {string} The URL for the phishing warning page, or `undefined` if no URL is set.
|
|
|
|
*/
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
function getPhishingWarningPageUrl({ config, testing }) {
|
|
|
|
let phishingWarningPageUrl = config.PHISHING_WARNING_PAGE_URL;
|
|
|
|
|
|
|
|
if (!phishingWarningPageUrl) {
|
|
|
|
phishingWarningPageUrl = testing
|
|
|
|
? 'http://localhost:9999/'
|
|
|
|
: 'https://metamask.github.io/phishing-warning/v1.1.0/';
|
|
|
|
}
|
|
|
|
|
|
|
|
// We add a hash/fragment to the URL dynamically, so we need to ensure it
|
|
|
|
// has a valid pathname to append a hash to.
|
|
|
|
const normalizedUrl = phishingWarningPageUrl.endsWith('/')
|
|
|
|
? phishingWarningPageUrl
|
|
|
|
: `${phishingWarningPageUrl}/`;
|
|
|
|
|
|
|
|
let phishingWarningPageUrlObject;
|
|
|
|
try {
|
|
|
|
// eslint-disable-next-line no-new
|
|
|
|
phishingWarningPageUrlObject = new URL(normalizedUrl);
|
|
|
|
} catch (error) {
|
|
|
|
throw new Error(
|
|
|
|
`Invalid phishing warning page URL: '${normalizedUrl}'`,
|
|
|
|
error,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
if (phishingWarningPageUrlObject.hash) {
|
|
|
|
// The URL fragment must be set dynamically
|
|
|
|
throw new Error(
|
|
|
|
`URL fragment not allowed in phishing warning page URL: '${normalizedUrl}'`,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
return normalizedUrl;
|
|
|
|
}
|
|
|
|
|
|
|
|
const noopWriteStream = through.obj((_file, _fileEncoding, callback) =>
|
|
|
|
callback(),
|
|
|
|
);
|
|
|
|
|
|
|
|
module.exports = createScriptTasks;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Create tasks for building JavaScript bundles and templates. One
|
|
|
|
* task is returned for each build target. These build target tasks are
|
|
|
|
* each composed of smaller tasks.
|
|
|
|
*
|
|
|
|
* @param {object} options - Build options.
|
|
|
|
* @param {boolean} options.applyLavaMoat - Whether the build should use
|
|
|
|
* LavaMoat at runtime or not.
|
|
|
|
* @param {string[]} options.browserPlatforms - A list of browser platforms to
|
|
|
|
* build bundles for.
|
|
|
|
* @param {BuildType} options.buildType - The current build type (e.g. "main",
|
|
|
|
* "flask", etc.).
|
|
|
|
* @param {string[] | null} options.ignoredFiles - A list of files to exclude
|
|
|
|
* from the current build.
|
|
|
|
* @param {boolean} options.isLavaMoat - Whether this build script is being run
|
|
|
|
* using LavaMoat or not.
|
|
|
|
* @param {object} options.livereload - The "gulp-livereload" server instance.
|
|
|
|
* @param {boolean} options.policyOnly - Whether to stop the build after
|
|
|
|
* generating the LavaMoat policy, skipping any writes to disk other than the
|
|
|
|
* LavaMoat policy itself.
|
|
|
|
* @param {boolean} options.shouldLintFenceFiles - Whether files with code
|
|
|
|
* fences should be linted after fences have been removed.
|
|
|
|
* @param {string} options.version - The current version of the extension.
|
|
|
|
* @returns {object} A set of tasks, one for each build target.
|
|
|
|
*/
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
function createScriptTasks({
|
|
|
|
applyLavaMoat,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
browserPlatforms,
|
|
|
|
buildType,
|
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
|
|
|
ignoredFiles,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
isLavaMoat,
|
|
|
|
livereload,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
}) {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
// high level tasks
|
|
|
|
return {
|
|
|
|
// dev tasks (live reload)
|
|
|
|
dev: createTasksForScriptBundles({
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
buildTarget: BUILD_TARGETS.DEV,
|
|
|
|
taskPrefix: 'scripts:core:dev',
|
|
|
|
}),
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
// production-like distributable build
|
|
|
|
dist: createTasksForScriptBundles({
|
|
|
|
buildTarget: BUILD_TARGETS.DIST,
|
|
|
|
taskPrefix: 'scripts:core:dist',
|
|
|
|
}),
|
|
|
|
// production
|
|
|
|
prod: createTasksForScriptBundles({
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
buildTarget: BUILD_TARGETS.PROD,
|
|
|
|
taskPrefix: 'scripts:core:prod',
|
|
|
|
}),
|
|
|
|
// built for CI tests
|
|
|
|
test: createTasksForScriptBundles({
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
buildTarget: BUILD_TARGETS.TEST,
|
|
|
|
taskPrefix: 'scripts:core:test',
|
|
|
|
}),
|
|
|
|
// built for CI test debugging
|
|
|
|
testDev: createTasksForScriptBundles({
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
buildTarget: BUILD_TARGETS.TEST_DEV,
|
|
|
|
taskPrefix: 'scripts:core:test-live',
|
|
|
|
}),
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Define tasks for building the JavaScript modules used by the extension.
|
|
|
|
* This function returns a single task that builds JavaScript modules in
|
|
|
|
* parallel for a single type of build (e.g. dev, testing, production).
|
|
|
|
*
|
|
|
|
* @param {object} options - The build options.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The build target that these
|
|
|
|
* JavaScript modules are intended for.
|
|
|
|
* @param {string} options.taskPrefix - The prefix to use for the name of
|
|
|
|
* each defined task.
|
|
|
|
*/
|
|
|
|
function createTasksForScriptBundles({ buildTarget, taskPrefix }) {
|
|
|
|
const standardEntryPoints = ['background', 'ui', 'content-script'];
|
|
|
|
const standardSubtask = createTask(
|
|
|
|
`${taskPrefix}:standardEntryPoints`,
|
|
|
|
createFactoredBuild({
|
|
|
|
applyLavaMoat,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
browserPlatforms,
|
|
|
|
buildTarget,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
buildType,
|
|
|
|
entryFiles: standardEntryPoints.map((label) => {
|
|
|
|
if (label === 'content-script') {
|
|
|
|
return './app/vendor/trezor/content-script.js';
|
|
|
|
}
|
|
|
|
return `./app/scripts/${label}.js`;
|
|
|
|
}),
|
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
|
|
|
ignoredFiles,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
}),
|
|
|
|
);
|
|
|
|
|
|
|
|
// inpage must be built before contentscript
|
|
|
|
// because inpage bundle result is included inside contentscript
|
|
|
|
const contentscriptSubtask = createTask(
|
|
|
|
`${taskPrefix}:contentscript`,
|
|
|
|
createContentscriptBundle({ buildTarget }),
|
|
|
|
);
|
|
|
|
|
|
|
|
// this can run whenever
|
|
|
|
const disableConsoleSubtask = createTask(
|
|
|
|
`${taskPrefix}:disable-console`,
|
|
|
|
createDisableConsoleBundle({ buildTarget }),
|
|
|
|
);
|
|
|
|
|
|
|
|
// this can run whenever
|
|
|
|
const installSentrySubtask = createTask(
|
|
|
|
`${taskPrefix}:sentry`,
|
|
|
|
createSentryBundle({ buildTarget }),
|
|
|
|
);
|
|
|
|
|
|
|
|
// task for initiating browser livereload
|
|
|
|
const initiateLiveReload = async () => {
|
|
|
|
if (isDevBuild(buildTarget)) {
|
|
|
|
// trigger live reload when the bundles are updated
|
|
|
|
// this is not ideal, but overcomes the limitations:
|
|
|
|
// - run from the main process (not child process tasks)
|
|
|
|
// - after the first build has completed (thus the timeout)
|
|
|
|
// - build tasks never "complete" when run with livereload + child process
|
|
|
|
setTimeout(() => {
|
|
|
|
watch('./dist/*/*.js', (event) => {
|
|
|
|
livereload.changed(event.path);
|
|
|
|
});
|
|
|
|
}, 75e3);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
// make each bundle run in a separate process
|
|
|
|
const allSubtasks = [
|
|
|
|
standardSubtask,
|
|
|
|
contentscriptSubtask,
|
|
|
|
disableConsoleSubtask,
|
|
|
|
installSentrySubtask,
|
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>
3 years ago
|
|
|
].map((subtask) =>
|
|
|
|
runInChildProcess(subtask, {
|
|
|
|
applyLavaMoat,
|
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>
3 years ago
|
|
|
buildType,
|
|
|
|
isLavaMoat,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
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>
3 years ago
|
|
|
}),
|
|
|
|
);
|
|
|
|
// make a parent task that runs each task in a child thread
|
|
|
|
return composeParallel(initiateLiveReload, ...allSubtasks);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Create a bundle for the "disable-console" module.
|
|
|
|
*
|
|
|
|
* @param {object} options - The build options.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The current build target.
|
|
|
|
* @returns {Function} A function that creates the bundle.
|
|
|
|
*/
|
|
|
|
function createDisableConsoleBundle({ buildTarget }) {
|
|
|
|
const label = 'disable-console';
|
|
|
|
return createNormalBundle({
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
browserPlatforms,
|
|
|
|
buildTarget,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
buildType,
|
|
|
|
destFilepath: `${label}.js`,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
entryFilepath: `./app/scripts/${label}.js`,
|
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
|
|
|
ignoredFiles,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
label,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Create a bundle for the "sentry-install" module.
|
|
|
|
*
|
|
|
|
* @param {object} options - The build options.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The current build target.
|
|
|
|
* @returns {Function} A function that creates the bundle.
|
|
|
|
*/
|
|
|
|
function createSentryBundle({ buildTarget }) {
|
|
|
|
const label = 'sentry-install';
|
|
|
|
return createNormalBundle({
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
browserPlatforms,
|
|
|
|
buildTarget,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
buildType,
|
|
|
|
destFilepath: `${label}.js`,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
entryFilepath: `./app/scripts/${label}.js`,
|
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
|
|
|
ignoredFiles,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
label,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Create bundles for the "contentscript" and "inpage" modules. The inpage
|
|
|
|
* module is created first because it gets embedded in the contentscript
|
|
|
|
* module.
|
|
|
|
*
|
|
|
|
* @param {object} options - The build options.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The current build target.
|
|
|
|
* @returns {Function} A function that creates the bundles.
|
|
|
|
*/
|
|
|
|
function createContentscriptBundle({ buildTarget }) {
|
|
|
|
const inpage = 'inpage';
|
|
|
|
const contentscript = 'contentscript';
|
|
|
|
return composeSeries(
|
|
|
|
createNormalBundle({
|
|
|
|
buildTarget,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
buildType,
|
|
|
|
browserPlatforms,
|
|
|
|
destFilepath: `${inpage}.js`,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
entryFilepath: `./app/scripts/${inpage}.js`,
|
|
|
|
label: inpage,
|
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
|
|
|
ignoredFiles,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
}),
|
|
|
|
createNormalBundle({
|
|
|
|
buildTarget,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
buildType,
|
|
|
|
browserPlatforms,
|
|
|
|
destFilepath: `${contentscript}.js`,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
entryFilepath: `./app/scripts/${contentscript}.js`,
|
|
|
|
label: contentscript,
|
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
|
|
|
ignoredFiles,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
}),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Create the bundle for the app initialization module used in manifest v3
|
|
|
|
* builds.
|
|
|
|
*
|
|
|
|
* This must be called after the "background" bundles have been created, so
|
|
|
|
* that the list of all background bundles can be injected into this bundle.
|
|
|
|
*
|
|
|
|
* @param {object} options - Build options.
|
|
|
|
* @param {boolean} options.applyLavaMoat - Whether the build should use
|
|
|
|
* LavaMoat at runtime or not.
|
|
|
|
* @param {string[]} options.browserPlatforms - A list of browser platforms to
|
|
|
|
* build bundles for.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The current build target.
|
|
|
|
* @param {BuildType} options.buildType - The current build type (e.g. "main",
|
|
|
|
* "flask", etc.).
|
|
|
|
* @param {string[] | null} options.ignoredFiles - A list of files to exclude
|
|
|
|
* from the current build.
|
|
|
|
* @param {string[]} options.jsBundles - A list of JavaScript bundles to be
|
|
|
|
* injected into this bundle.
|
|
|
|
* @param {boolean} options.policyOnly - Whether to stop the build after
|
|
|
|
* generating the LavaMoat policy, skipping any writes to disk other than the
|
|
|
|
* LavaMoat policy itself.
|
|
|
|
* @param {boolean} options.shouldLintFenceFiles - Whether files with code
|
|
|
|
* fences should be linted after fences have been removed.
|
|
|
|
* @param {string} options.version - The current version of the extension.
|
|
|
|
* @returns {Function} A function that creates the set of bundles.
|
|
|
|
*/
|
|
|
|
async function createManifestV3AppInitializationBundle({
|
|
|
|
applyLavaMoat,
|
|
|
|
browserPlatforms,
|
|
|
|
buildTarget,
|
|
|
|
buildType,
|
|
|
|
ignoredFiles,
|
|
|
|
jsBundles,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
}) {
|
|
|
|
const label = 'app-init';
|
|
|
|
// TODO: remove this filter for firefox once MV3 is supported in it
|
|
|
|
const mv3BrowserPlatforms = browserPlatforms.filter(
|
|
|
|
(platform) => platform !== 'firefox',
|
|
|
|
);
|
|
|
|
|
|
|
|
for (const filename of jsBundles) {
|
|
|
|
if (filename.includes(',')) {
|
|
|
|
throw new Error(
|
|
|
|
`Invalid filename "${filename}", not allowed to contain comma.`,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
const extraEnvironmentVariables = {
|
|
|
|
APPLY_LAVAMOAT: applyLavaMoat,
|
|
|
|
FILE_NAMES: jsBundles.join(','),
|
|
|
|
};
|
|
|
|
|
|
|
|
await createNormalBundle({
|
|
|
|
browserPlatforms: mv3BrowserPlatforms,
|
|
|
|
buildTarget,
|
|
|
|
buildType,
|
|
|
|
destFilepath: 'app-init.js',
|
|
|
|
entryFilepath: './app/scripts/app-init.js',
|
|
|
|
extraEnvironmentVariables,
|
|
|
|
ignoredFiles,
|
|
|
|
label,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
})();
|
|
|
|
|
|
|
|
// Code below is used to set statsMode to true when testing in MV3
|
|
|
|
// This is used to capture module initialisation stats using lavamoat.
|
|
|
|
if (isTestBuild(buildTarget)) {
|
|
|
|
const content = readFileSync('./dist/chrome/runtime-lavamoat.js', 'utf8');
|
|
|
|
const fileOutput = content.replace('statsMode = false', 'statsMode = true');
|
|
|
|
writeFileSync('./dist/chrome/runtime-lavamoat.js', fileOutput);
|
|
|
|
}
|
|
|
|
|
|
|
|
console.log(`Bundle end: service worker app-init.js`);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return a function that creates a set of factored bundles.
|
|
|
|
*
|
|
|
|
* For each entry point, a series of one or more bundles is created. These are
|
|
|
|
* split up roughly by size, to ensure no single bundle exceeds the maximum
|
|
|
|
* JavaScript file size imposed by Firefox.
|
|
|
|
*
|
|
|
|
* Modules that are common between all entry points are bundled separately, as
|
|
|
|
* a set of one or more "common" bundles.
|
|
|
|
*
|
|
|
|
* @param {object} options - Build options.
|
|
|
|
* @param {boolean} options.applyLavaMoat - Whether the build should use
|
|
|
|
* LavaMoat at runtime or not.
|
|
|
|
* @param {string[]} options.browserPlatforms - A list of browser platforms to
|
|
|
|
* build bundles for.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The current build target.
|
|
|
|
* @param {BuildType} options.buildType - The current build type (e.g. "main",
|
|
|
|
* "flask", etc.).
|
|
|
|
* @param {string[]} options.entryFiles - A list of entry point file paths,
|
|
|
|
* relative to the repository root directory.
|
|
|
|
* @param {string[] | null} options.ignoredFiles - A list of files to exclude
|
|
|
|
* from the current build.
|
|
|
|
* @param {boolean} options.policyOnly - Whether to stop the build after
|
|
|
|
* generating the LavaMoat policy, skipping any writes to disk other than the
|
|
|
|
* LavaMoat policy itself.
|
|
|
|
* @param {boolean} options.shouldLintFenceFiles - Whether files with code
|
|
|
|
* fences should be linted after fences have been removed.
|
|
|
|
* @param {string} options.version - The current version of the extension.
|
|
|
|
* @returns {Function} A function that creates the set of bundles.
|
|
|
|
*/
|
|
|
|
function createFactoredBuild({
|
|
|
|
applyLavaMoat,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
browserPlatforms,
|
|
|
|
buildTarget,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
buildType,
|
|
|
|
entryFiles,
|
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
|
|
|
ignoredFiles,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
}) {
|
|
|
|
return async function () {
|
|
|
|
// create bundler setup and apply defaults
|
|
|
|
const buildConfiguration = createBuildConfiguration();
|
|
|
|
buildConfiguration.label = 'primary';
|
|
|
|
const { bundlerOpts, events } = buildConfiguration;
|
|
|
|
|
|
|
|
// devMode options
|
|
|
|
const reloadOnChange = isDevBuild(buildTarget);
|
|
|
|
const minify = !isDevBuild(buildTarget);
|
|
|
|
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
const envVars = await getEnvironmentVariables({
|
|
|
|
buildTarget,
|
|
|
|
buildType,
|
|
|
|
version,
|
|
|
|
});
|
|
|
|
setupBundlerDefaults(buildConfiguration, {
|
|
|
|
buildTarget,
|
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>
3 years ago
|
|
|
buildType,
|
|
|
|
envVars,
|
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
|
|
|
ignoredFiles,
|
|
|
|
policyOnly,
|
|
|
|
minify,
|
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>
3 years ago
|
|
|
reloadOnChange,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
});
|
|
|
|
|
|
|
|
// set bundle entries
|
|
|
|
bundlerOpts.entries = [...entryFiles];
|
|
|
|
|
|
|
|
// setup lavamoat
|
|
|
|
// lavamoat will add lavapack but it will be removed by bify-module-groups
|
|
|
|
// we will re-add it later by installing a lavapack runtime
|
|
|
|
const lavamoatOpts = {
|
|
|
|
policy: path.resolve(
|
|
|
|
__dirname,
|
|
|
|
`../../lavamoat/browserify/${buildType}/policy.json`,
|
|
|
|
),
|
|
|
|
policyName: buildType,
|
|
|
|
policyOverride: path.resolve(
|
|
|
|
__dirname,
|
|
|
|
`../../lavamoat/browserify/policy-override.json`,
|
|
|
|
),
|
|
|
|
writeAutoPolicy: process.env.WRITE_AUTO_POLICY,
|
|
|
|
};
|
|
|
|
Object.assign(bundlerOpts, lavamoatBrowserify.args);
|
|
|
|
bundlerOpts.plugin.push([lavamoatBrowserify, lavamoatOpts]);
|
|
|
|
|
|
|
|
// setup bundle factoring with bify-module-groups plugin
|
|
|
|
// note: this will remove lavapack, but its ok bc we manually readd it later
|
|
|
|
Object.assign(bundlerOpts, bifyModuleGroups.plugin.args);
|
|
|
|
bundlerOpts.plugin = [...bundlerOpts.plugin, [bifyModuleGroups.plugin]];
|
|
|
|
|
|
|
|
// instrument pipeline
|
|
|
|
let sizeGroupMap;
|
|
|
|
events.on('configurePipeline', ({ pipeline }) => {
|
|
|
|
// to be populated by the group-by-size transform
|
|
|
|
sizeGroupMap = new Map();
|
|
|
|
pipeline.get('groups').unshift(
|
|
|
|
// factor modules
|
|
|
|
bifyModuleGroups.groupByFactor({
|
|
|
|
entryFileToLabel(filepath) {
|
|
|
|
return path.parse(filepath).name;
|
|
|
|
},
|
|
|
|
}),
|
|
|
|
// cap files at 2 mb
|
|
|
|
bifyModuleGroups.groupBySize({
|
|
|
|
sizeLimit: 2e6,
|
|
|
|
groupingMap: sizeGroupMap,
|
|
|
|
}),
|
|
|
|
);
|
|
|
|
// converts each module group into a single vinyl file containing its bundle
|
|
|
|
const moduleGroupPackerStream = streamFlatMap((moduleGroup) => {
|
|
|
|
const filename = `${moduleGroup.label}.js`;
|
|
|
|
const childStream = wrapInStream(
|
|
|
|
moduleGroup.stream,
|
|
|
|
// we manually readd lavapack here bc bify-module-groups removes it
|
|
|
|
lavapack({ raw: true, hasExports: true, includePrelude: false }),
|
|
|
|
source(filename),
|
|
|
|
);
|
|
|
|
return childStream;
|
|
|
|
});
|
|
|
|
pipeline.get('vinyl').unshift(moduleGroupPackerStream, buffer());
|
|
|
|
// add lavamoat policy loader file to packer output
|
|
|
|
moduleGroupPackerStream.push(
|
|
|
|
new Vinyl({
|
|
|
|
path: 'policy-load.js',
|
|
|
|
contents: lavapack.makePolicyLoaderStream(lavamoatOpts),
|
|
|
|
}),
|
|
|
|
);
|
|
|
|
// setup bundle destination
|
|
|
|
browserPlatforms.forEach((platform) => {
|
|
|
|
const dest = `./dist/${platform}/`;
|
|
|
|
const destination = policyOnly ? noopWriteStream : gulp.dest(dest);
|
|
|
|
pipeline.get('dest').push(destination);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
// wait for bundle completion for postprocessing
|
|
|
|
events.on('bundleDone', async () => {
|
|
|
|
// Skip HTML generation if nothing is to be written to disk
|
|
|
|
if (policyOnly) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const commonSet = sizeGroupMap.get('common');
|
|
|
|
// create entry points for each file
|
|
|
|
for (const [groupLabel, groupSet] of sizeGroupMap.entries()) {
|
|
|
|
// skip "common" group, they are added to all other groups
|
|
|
|
if (groupSet === commonSet) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (groupLabel) {
|
|
|
|
case 'ui': {
|
|
|
|
renderHtmlFile({
|
|
|
|
htmlName: 'popup',
|
|
|
|
groupSet,
|
|
|
|
commonSet,
|
|
|
|
browserPlatforms,
|
|
|
|
applyLavaMoat,
|
|
|
|
});
|
|
|
|
renderHtmlFile({
|
|
|
|
htmlName: 'notification',
|
|
|
|
groupSet,
|
|
|
|
commonSet,
|
|
|
|
browserPlatforms,
|
|
|
|
applyLavaMoat,
|
|
|
|
});
|
|
|
|
renderHtmlFile({
|
|
|
|
htmlName: 'home',
|
|
|
|
groupSet,
|
|
|
|
commonSet,
|
|
|
|
browserPlatforms,
|
|
|
|
applyLavaMoat,
|
|
|
|
});
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case 'background': {
|
|
|
|
renderHtmlFile({
|
|
|
|
htmlName: 'background',
|
|
|
|
groupSet,
|
|
|
|
commonSet,
|
|
|
|
browserPlatforms,
|
|
|
|
applyLavaMoat,
|
|
|
|
});
|
|
|
|
if (process.env.ENABLE_MV3) {
|
|
|
|
const jsBundles = [
|
|
|
|
...commonSet.values(),
|
|
|
|
...groupSet.values(),
|
|
|
|
].map((label) => `./${label}.js`);
|
|
|
|
await createManifestV3AppInitializationBundle({
|
|
|
|
applyLavaMoat,
|
|
|
|
browserPlatforms,
|
|
|
|
buildTarget,
|
|
|
|
buildType,
|
|
|
|
ignoredFiles,
|
|
|
|
jsBundles,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
});
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case 'content-script': {
|
|
|
|
renderHtmlFile({
|
|
|
|
htmlName: 'trezor-usb-permissions',
|
|
|
|
groupSet,
|
|
|
|
commonSet,
|
|
|
|
browserPlatforms,
|
|
|
|
applyLavaMoat: false,
|
|
|
|
});
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default: {
|
|
|
|
throw new Error(
|
|
|
|
`build/scripts - unknown groupLabel "${groupLabel}"`,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
await createBundle(buildConfiguration, { reloadOnChange });
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return a function that creates a single JavaScript bundle.
|
|
|
|
*
|
|
|
|
* @param {object} options - Build options.
|
|
|
|
* @param {string[]} options.browserPlatforms - A list of browser platforms to
|
|
|
|
* build the bundle for.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The current build target.
|
|
|
|
* @param {BuildType} options.buildType - The current build type (e.g. "main",
|
|
|
|
* "flask", etc.).
|
|
|
|
* @param {string} options.destFilepath - The file path the bundle should be
|
|
|
|
* written to.
|
|
|
|
* @param {string[]} options.entryFilepath - The entry point file path,
|
|
|
|
* relative to the repository root directory.
|
|
|
|
* @param {Record<string, unknown>} options.extraEnvironmentVariables - Extra
|
|
|
|
* environment variables to inject just into this bundle.
|
|
|
|
* @param {string[] | null} options.ignoredFiles - A list of files to exclude
|
|
|
|
* from the current build.
|
|
|
|
* @param {string} options.label - A label used to describe this bundle in any
|
|
|
|
* diagnostic messages.
|
|
|
|
* @param {boolean} options.policyOnly - Whether to stop the build after
|
|
|
|
* generating the LavaMoat policy, skipping any writes to disk other than the
|
|
|
|
* LavaMoat policy itself.
|
|
|
|
* @param {boolean} options.shouldLintFenceFiles - Whether files with code
|
|
|
|
* fences should be linted after fences have been removed.
|
|
|
|
* @param {string} options.version - The current version of the extension.
|
|
|
|
* @returns {Function} A function that creates the bundle.
|
|
|
|
*/
|
|
|
|
function createNormalBundle({
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
browserPlatforms,
|
|
|
|
buildTarget,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
buildType,
|
|
|
|
destFilepath,
|
|
|
|
entryFilepath,
|
|
|
|
extraEnvironmentVariables,
|
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
|
|
|
ignoredFiles,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
label,
|
|
|
|
policyOnly,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
version,
|
|
|
|
}) {
|
|
|
|
return async function () {
|
|
|
|
// create bundler setup and apply defaults
|
|
|
|
const buildConfiguration = createBuildConfiguration();
|
|
|
|
buildConfiguration.label = label;
|
|
|
|
const { bundlerOpts, events } = buildConfiguration;
|
|
|
|
|
|
|
|
// devMode options
|
|
|
|
const devMode = isDevBuild(buildTarget);
|
|
|
|
const reloadOnChange = Boolean(devMode);
|
|
|
|
const minify = Boolean(devMode) === false;
|
|
|
|
|
|
|
|
const envVars = {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
...(await getEnvironmentVariables({
|
|
|
|
buildTarget,
|
|
|
|
buildType,
|
|
|
|
version,
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
})),
|
|
|
|
...extraEnvironmentVariables,
|
|
|
|
};
|
|
|
|
setupBundlerDefaults(buildConfiguration, {
|
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>
3 years ago
|
|
|
buildType,
|
|
|
|
envVars,
|
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
|
|
|
ignoredFiles,
|
|
|
|
policyOnly,
|
|
|
|
minify,
|
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>
3 years ago
|
|
|
reloadOnChange,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
});
|
|
|
|
|
|
|
|
// set bundle entries
|
|
|
|
bundlerOpts.entries = [entryFilepath];
|
|
|
|
|
|
|
|
// instrument pipeline
|
|
|
|
events.on('configurePipeline', ({ pipeline }) => {
|
|
|
|
// convert bundle stream to gulp vinyl stream
|
|
|
|
// and ensure file contents are buffered
|
|
|
|
pipeline.get('vinyl').push(source(destFilepath));
|
|
|
|
pipeline.get('vinyl').push(buffer());
|
|
|
|
// setup bundle destination
|
|
|
|
browserPlatforms.forEach((platform) => {
|
|
|
|
const dest = `./dist/${platform}/`;
|
|
|
|
const destination = policyOnly ? noopWriteStream : gulp.dest(dest);
|
|
|
|
pipeline.get('dest').push(destination);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
await createBundle(buildConfiguration, { reloadOnChange });
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
function createBuildConfiguration() {
|
|
|
|
const label = '(unnamed bundle)';
|
|
|
|
const events = new EventEmitter();
|
|
|
|
const bundlerOpts = {
|
|
|
|
entries: [],
|
|
|
|
transform: [],
|
|
|
|
plugin: [],
|
|
|
|
require: [],
|
|
|
|
// non-standard bify options
|
|
|
|
manualExternal: [],
|
|
|
|
manualIgnore: [],
|
|
|
|
};
|
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
|
|
|
return { bundlerOpts, events, label };
|
|
|
|
}
|
|
|
|
|
|
|
|
function setupBundlerDefaults(
|
|
|
|
buildConfiguration,
|
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
|
|
|
{
|
|
|
|
buildTarget,
|
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
|
|
|
buildType,
|
|
|
|
envVars,
|
|
|
|
ignoredFiles,
|
|
|
|
policyOnly,
|
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
|
|
|
minify,
|
|
|
|
reloadOnChange,
|
|
|
|
shouldLintFenceFiles,
|
|
|
|
},
|
|
|
|
) {
|
|
|
|
const { bundlerOpts } = buildConfiguration;
|
Add TypeScript to the build system (#13489)
This commit modifies the build system so that TypeScript files can be
transpiled into ES5 just like JavaScript files.
Note that this commit does NOT change the build system to run TypeScript
files through the TypeScript compiler. In other words, no files will be
type-checked at the build stage, as we expect type-checking to be
handled elsewhere (live, via your editor integration with `tsserver`,
and before a PR is merged, via `yarn lint`). Rather, we merely instruct
Babel to strip TypeScript-specific syntax from any files that have it,
as if those files had been written using JavaScript syntax alone.
Why take this approach? Because it prevents the build process from being
negatively impacted with respect to performance (as TypeScript takes a
significant amount of time to run).
It's worth noting the downside of this approach: because we aren't
running files through TypeScript, but relying on Babel's [TypeScript
transform][1] to identify TypeScript syntax, this transform has to keep
up with any syntax changes that TypeScript adds in the future. In fact
there are a few syntactical forms that Babel already does not recognize.
These forms are rare or are deprecated by TypeScript, so I don't
consider them to be a blocker, but it's worth noting just in case it
comes up later. Also, any settings we place in `tsconfig.json` will be
completely ignored by Babel. Again, this isn't a blocker because there
are some analogs for the most important settings reflected in the
options we can pass to the transform. These and other caveats are
detailed in the [documentation for the transform][2].
[1]: https://babeljs.io/docs/en/babel-plugin-transform-typescript
[2]: https://babeljs.io/docs/en/babel-plugin-transform-typescript#caveats
3 years ago
|
|
|
const extensions = ['.js', '.ts', '.tsx'];
|
|
|
|
|
|
|
|
Object.assign(bundlerOpts, {
|
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>
3 years ago
|
|
|
// Source transforms
|
|
|
|
transform: [
|
|
|
|
// // Remove code that should be excluded from builds of the current type
|
|
|
|
createRemoveFencedCodeTransform(buildType, shouldLintFenceFiles),
|
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>
3 years ago
|
|
|
// Transpile top-level code
|
Add TypeScript to the build system (#13489)
This commit modifies the build system so that TypeScript files can be
transpiled into ES5 just like JavaScript files.
Note that this commit does NOT change the build system to run TypeScript
files through the TypeScript compiler. In other words, no files will be
type-checked at the build stage, as we expect type-checking to be
handled elsewhere (live, via your editor integration with `tsserver`,
and before a PR is merged, via `yarn lint`). Rather, we merely instruct
Babel to strip TypeScript-specific syntax from any files that have it,
as if those files had been written using JavaScript syntax alone.
Why take this approach? Because it prevents the build process from being
negatively impacted with respect to performance (as TypeScript takes a
significant amount of time to run).
It's worth noting the downside of this approach: because we aren't
running files through TypeScript, but relying on Babel's [TypeScript
transform][1] to identify TypeScript syntax, this transform has to keep
up with any syntax changes that TypeScript adds in the future. In fact
there are a few syntactical forms that Babel already does not recognize.
These forms are rare or are deprecated by TypeScript, so I don't
consider them to be a blocker, but it's worth noting just in case it
comes up later. Also, any settings we place in `tsconfig.json` will be
completely ignored by Babel. Again, this isn't a blocker because there
are some analogs for the most important settings reflected in the
options we can pass to the transform. These and other caveats are
detailed in the [documentation for the transform][2].
[1]: https://babeljs.io/docs/en/babel-plugin-transform-typescript
[2]: https://babeljs.io/docs/en/babel-plugin-transform-typescript#caveats
3 years ago
|
|
|
[
|
|
|
|
babelify,
|
|
|
|
// Run TypeScript files through Babel
|
|
|
|
{ extensions },
|
|
|
|
],
|
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>
3 years ago
|
|
|
// Inline `fs.readFileSync` files
|
|
|
|
brfs,
|
|
|
|
],
|
Add TypeScript to the build system (#13489)
This commit modifies the build system so that TypeScript files can be
transpiled into ES5 just like JavaScript files.
Note that this commit does NOT change the build system to run TypeScript
files through the TypeScript compiler. In other words, no files will be
type-checked at the build stage, as we expect type-checking to be
handled elsewhere (live, via your editor integration with `tsserver`,
and before a PR is merged, via `yarn lint`). Rather, we merely instruct
Babel to strip TypeScript-specific syntax from any files that have it,
as if those files had been written using JavaScript syntax alone.
Why take this approach? Because it prevents the build process from being
negatively impacted with respect to performance (as TypeScript takes a
significant amount of time to run).
It's worth noting the downside of this approach: because we aren't
running files through TypeScript, but relying on Babel's [TypeScript
transform][1] to identify TypeScript syntax, this transform has to keep
up with any syntax changes that TypeScript adds in the future. In fact
there are a few syntactical forms that Babel already does not recognize.
These forms are rare or are deprecated by TypeScript, so I don't
consider them to be a blocker, but it's worth noting just in case it
comes up later. Also, any settings we place in `tsconfig.json` will be
completely ignored by Babel. Again, this isn't a blocker because there
are some analogs for the most important settings reflected in the
options we can pass to the transform. These and other caveats are
detailed in the [documentation for the transform][2].
[1]: https://babeljs.io/docs/en/babel-plugin-transform-typescript
[2]: https://babeljs.io/docs/en/babel-plugin-transform-typescript#caveats
3 years ago
|
|
|
// Look for TypeScript files when walking the dependency tree
|
|
|
|
extensions,
|
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>
3 years ago
|
|
|
// Use entryFilepath for moduleIds, easier to determine origin file
|
|
|
|
fullPaths: isDevBuild(buildTarget) || isTestBuild(buildTarget),
|
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>
3 years ago
|
|
|
// For sourcemaps
|
|
|
|
debug: true,
|
|
|
|
});
|
|
|
|
|
|
|
|
// Ensure react-devtools is only included in dev builds
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
if (buildTarget !== BUILD_TARGETS.DEV) {
|
|
|
|
bundlerOpts.manualIgnore.push('react-devtools');
|
|
|
|
bundlerOpts.manualIgnore.push('remote-redux-devtools');
|
|
|
|
}
|
|
|
|
|
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>
3 years ago
|
|
|
// Inject environment variables via node-style `process.env`
|
|
|
|
if (envVars) {
|
|
|
|
bundlerOpts.transform.push([envify(envVars), { global: true }]);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// Ensure that any files that should be ignored are excluded from the build
|
|
|
|
if (ignoredFiles) {
|
|
|
|
bundlerOpts.manualExclude = ignoredFiles;
|
|
|
|
}
|
|
|
|
|
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>
3 years ago
|
|
|
// Setup reload on change
|
|
|
|
if (reloadOnChange) {
|
|
|
|
setupReloadOnChange(buildConfiguration);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!policyOnly) {
|
|
|
|
if (minify) {
|
|
|
|
setupMinification(buildConfiguration);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Setup source maps
|
|
|
|
setupSourcemaps(buildConfiguration, { buildTarget });
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function setupReloadOnChange({ bundlerOpts, events }) {
|
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>
3 years ago
|
|
|
// Add plugin to options
|
|
|
|
Object.assign(bundlerOpts, {
|
|
|
|
plugin: [...bundlerOpts.plugin, watchify],
|
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>
3 years ago
|
|
|
// Required by watchify
|
|
|
|
cache: {},
|
|
|
|
packageCache: {},
|
|
|
|
});
|
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>
3 years ago
|
|
|
// Instrument pipeline
|
|
|
|
events.on('configurePipeline', ({ bundleStream }) => {
|
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>
3 years ago
|
|
|
// Handle build error to avoid breaking build process
|
|
|
|
// (eg on syntax error)
|
|
|
|
bundleStream.on('error', (err) => {
|
|
|
|
gracefulError(err);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
function setupMinification(buildConfiguration) {
|
|
|
|
const minifyOpts = {
|
|
|
|
mangle: {
|
|
|
|
reserved: ['MetamaskInpageProvider'],
|
|
|
|
},
|
|
|
|
};
|
|
|
|
const { events } = buildConfiguration;
|
|
|
|
events.on('configurePipeline', ({ pipeline }) => {
|
|
|
|
pipeline.get('minify').push(
|
|
|
|
// this is the "gulp-terser-js" wrapper around the latest version of terser
|
|
|
|
through.obj(
|
|
|
|
callbackify(async (file, _enc) => {
|
|
|
|
const input = {
|
|
|
|
[file.sourceMap.file]: file.contents.toString(),
|
|
|
|
};
|
|
|
|
const opts = {
|
|
|
|
sourceMap: {
|
|
|
|
filename: file.sourceMap.file,
|
|
|
|
content: file.sourceMap,
|
|
|
|
},
|
|
|
|
...minifyOpts,
|
|
|
|
};
|
|
|
|
const res = await terser.minify(input, opts);
|
|
|
|
file.contents = Buffer.from(res.code);
|
|
|
|
applySourceMap(file, res.map);
|
|
|
|
return file;
|
|
|
|
}),
|
|
|
|
),
|
|
|
|
);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
function setupSourcemaps(buildConfiguration, { buildTarget }) {
|
|
|
|
const { events } = buildConfiguration;
|
|
|
|
events.on('configurePipeline', ({ pipeline }) => {
|
|
|
|
pipeline.get('sourcemaps:init').push(sourcemaps.init({ loadMaps: true }));
|
|
|
|
pipeline
|
|
|
|
.get('sourcemaps:write')
|
|
|
|
// Use inline source maps for development due to Chrome DevTools bug
|
|
|
|
// https://bugs.chromium.org/p/chromium/issues/detail?id=931675
|
|
|
|
.push(
|
|
|
|
isDevBuild(buildTarget)
|
|
|
|
? sourcemaps.write()
|
|
|
|
: sourcemaps.write('../sourcemaps', { addComment: false }),
|
|
|
|
);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
async function createBundle(buildConfiguration, { reloadOnChange }) {
|
|
|
|
const { label, bundlerOpts, events } = buildConfiguration;
|
|
|
|
const bundler = browserify(bundlerOpts);
|
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
|
|
|
|
|
|
|
// manually apply non-standard options
|
|
|
|
bundler.external(bundlerOpts.manualExternal);
|
|
|
|
bundler.ignore(bundlerOpts.manualIgnore);
|
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
|
|
|
if (Array.isArray(bundlerOpts.manualExclude)) {
|
|
|
|
bundler.exclude(bundlerOpts.manualExclude);
|
|
|
|
}
|
|
|
|
|
|
|
|
// output build logs to terminal
|
|
|
|
bundler.on('log', log);
|
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
|
|
|
|
|
|
|
// forward update event (used by watchify)
|
|
|
|
bundler.on('update', () => performBundle());
|
|
|
|
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
console.log(`Bundle start: "${label}"`);
|
|
|
|
await performBundle();
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
console.log(`Bundle end: "${label}"`);
|
|
|
|
|
|
|
|
async function performBundle() {
|
|
|
|
// this pipeline is created for every bundle
|
|
|
|
// the labels are all the steps you can hook into
|
|
|
|
const pipeline = labeledStreamSplicer([
|
|
|
|
'groups',
|
|
|
|
[],
|
|
|
|
'vinyl',
|
|
|
|
[],
|
|
|
|
'sourcemaps:init',
|
|
|
|
[],
|
|
|
|
'minify',
|
|
|
|
[],
|
|
|
|
'sourcemaps:write',
|
|
|
|
[],
|
|
|
|
'dest',
|
|
|
|
[],
|
|
|
|
]);
|
|
|
|
const bundleStream = bundler.bundle();
|
|
|
|
if (!reloadOnChange) {
|
|
|
|
bundleStream.on('error', (error) => {
|
|
|
|
console.error('Bundling failed! See details below.');
|
|
|
|
logError(error);
|
|
|
|
process.exit(1);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
// trigger build pipeline instrumentations
|
|
|
|
events.emit('configurePipeline', { pipeline, bundleStream });
|
|
|
|
// start bundle, send into pipeline
|
|
|
|
bundleStream.pipe(pipeline);
|
|
|
|
// nothing will consume pipeline, so let it flow
|
|
|
|
pipeline.resume();
|
|
|
|
|
|
|
|
await endOfStream(pipeline);
|
|
|
|
|
|
|
|
// call the completion event to handle any post-processing
|
|
|
|
events.emit('bundleDone');
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get environment variables to inject in the current build.
|
|
|
|
*
|
|
|
|
* @param {object} options - Build options.
|
|
|
|
* @param {BUILD_TARGETS} options.buildTarget - The current build target.
|
|
|
|
* @param {BuildType} options.buildType - The current build type (e.g. "main",
|
|
|
|
* "flask", etc.).
|
|
|
|
* @param {string} options.version - The current version of the extension.
|
|
|
|
* @returns {object} A map of environment variables to inject.
|
|
|
|
*/
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
async function getEnvironmentVariables({ buildTarget, buildType, version }) {
|
|
|
|
const environment = getEnvironment({ buildTarget });
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
const config =
|
|
|
|
environment === ENVIRONMENT.PRODUCTION
|
|
|
|
? await getProductionConfig(buildType)
|
|
|
|
: await getConfig();
|
|
|
|
|
|
|
|
const devMode = isDevBuild(buildTarget);
|
|
|
|
const testing = isTestBuild(buildTarget);
|
|
|
|
return {
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
COLLECTIBLES_V1: config.COLLECTIBLES_V1 === '1',
|
|
|
|
CONF: devMode ? config : {},
|
|
|
|
IN_TEST: testing,
|
|
|
|
INFURA_PROJECT_ID: getInfuraProjectId({
|
|
|
|
buildType,
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
config,
|
|
|
|
environment,
|
|
|
|
testing,
|
|
|
|
}),
|
|
|
|
PORTFOLIO_URL: ENVIRONMENT.PORTFOLIO_URL || 'https://portfolio.metamask.io',
|
|
|
|
METAMASK_DEBUG: devMode,
|
|
|
|
METAMASK_ENVIRONMENT: environment,
|
|
|
|
METAMASK_VERSION: version,
|
Rationalize build system arguments (#12047)
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
3 years ago
|
|
|
METAMASK_BUILD_TYPE: buildType,
|
|
|
|
NODE_ENV: devMode ? ENVIRONMENT.DEVELOPMENT : ENVIRONMENT.PRODUCTION,
|
Add validation to production build script (#15468)
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes #15003
2 years ago
|
|
|
ONBOARDING_V2: config.ONBOARDING_V2 === '1',
|
|
|
|
PHISHING_WARNING_PAGE_URL: getPhishingWarningPageUrl({ config, testing }),
|
|
|
|
PUBNUB_PUB_KEY: config.PUBNUB_PUB_KEY || '',
|
|
|
|
PUBNUB_SUB_KEY: config.PUBNUB_SUB_KEY || '',
|
|
|
|
SEGMENT_HOST: config.SEGMENT_HOST,
|
|
|
|
SEGMENT_WRITE_KEY: getSegmentWriteKey({ buildType, config, environment }),
|
|
|
|
SENTRY_DSN: config.SENTRY_DSN,
|
|
|
|
SENTRY_DSN_DEV: config.SENTRY_DSN_DEV,
|
|
|
|
SIWE_V1: config.SIWE_V1 === '1',
|
|
|
|
SWAPS_USE_DEV_APIS: config.SWAPS_USE_DEV_APIS === '1',
|
|
|
|
TOKEN_ALLOWANCE_IMPROVEMENTS: config.TOKEN_ALLOWANCE_IMPROVEMENTS === '1',
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
function renderHtmlFile({
|
|
|
|
htmlName,
|
|
|
|
groupSet,
|
|
|
|
commonSet,
|
|
|
|
browserPlatforms,
|
|
|
|
applyLavaMoat,
|
|
|
|
}) {
|
|
|
|
if (applyLavaMoat === undefined) {
|
|
|
|
throw new Error(
|
|
|
|
'build/scripts/renderHtmlFile - must specify "applyLavaMoat" option',
|
|
|
|
);
|
|
|
|
}
|
|
|
|
const htmlFilePath = `./app/${htmlName}.html`;
|
|
|
|
const htmlTemplate = readFileSync(htmlFilePath, 'utf8');
|
|
|
|
const jsBundles = [...commonSet.values(), ...groupSet.values()].map(
|
|
|
|
(label) => `./${label}.js`,
|
|
|
|
);
|
|
|
|
const htmlOutput = Sqrl.render(htmlTemplate, { jsBundles, applyLavaMoat });
|
|
|
|
browserPlatforms.forEach((platform) => {
|
|
|
|
const dest = `./dist/${platform}/${htmlName}.html`;
|
|
|
|
// we dont have a way of creating async events atm
|
|
|
|
writeFileSync(dest, htmlOutput);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
function beep() {
|
|
|
|
process.stdout.write('\x07');
|
|
|
|
}
|
|
|
|
|
|
|
|
function gracefulError(err) {
|
|
|
|
console.warn(err);
|
|
|
|
beep();
|
|
|
|
}
|