|
|
|
|
npm-debug.log
|
Switch from `npm` to `yarn` (#6843)
As a solution to the constant lockfile churn issues we've had with
`npm`, the project now uses `yarn` to manage dependencies.
The `package-lock.json` file has been replaced with `yarn.lock`, which
was created using `yarn import`. It should approximate the contents of
`package-lock.json` fairly well, though there may be some changes due to
deduplication. The codeowners file has been updated to reference this
new lockfile.
All documentation and npm scripts have been updated to reference `yarn`
rather than `npm`. Note that running scripts using `npm run` still works
fine, but it seemed better to switch those to `yarn` as well to avoid
confusion.
The `npm-audit` Bash script has been replaced with `yarn-audit`. The
output of `yarn audit` is a bit different than `npm audit` in that it
returns a bitmask to describe which severity issues were found. This
made it simpler to check the results directly from the Bash script, so
the associated `npm-audit-check.js` script was no longer required. The
output should be exactly the same, and the information is still sourced
from the same place (the npm registry).
The new `yarn-audit` script does have an external dependency: `jq`.
However, `jq` is already assumed to be present by another CI script, and
is present on all CI images we use. `jq` was not added to `package.json`
as a dependency because there is no official package on the npm
registry, just wrapper scripts. We don't need it anywhere exept on CI
anyway.
The section in `CONTRIBUTING` about how to develop inside the
`node_modules` folder was removed, as the advice was a bit dated, and
wasn't specific to this project anyway.
5 years ago
|
|
|
yarn-error.log
|
|
|
|
|
node_modules
|
Switch from `npm` to `yarn` (#6843)
As a solution to the constant lockfile churn issues we've had with
`npm`, the project now uses `yarn` to manage dependencies.
The `package-lock.json` file has been replaced with `yarn.lock`, which
was created using `yarn import`. It should approximate the contents of
`package-lock.json` fairly well, though there may be some changes due to
deduplication. The codeowners file has been updated to reference this
new lockfile.
All documentation and npm scripts have been updated to reference `yarn`
rather than `npm`. Note that running scripts using `npm run` still works
fine, but it seemed better to switch those to `yarn` as well to avoid
confusion.
The `npm-audit` Bash script has been replaced with `yarn-audit`. The
output of `yarn audit` is a bit different than `npm audit` in that it
returns a bitmask to describe which severity issues were found. This
made it simpler to check the results directly from the Bash script, so
the associated `npm-audit-check.js` script was no longer required. The
output should be exactly the same, and the information is still sourced
from the same place (the npm registry).
The new `yarn-audit` script does have an external dependency: `jq`.
However, `jq` is already assumed to be present by another CI script, and
is present on all CI images we use. `jq` was not added to `package.json`
as a dependency because there is no official package on the npm
registry, just wrapper scripts. We don't need it anywhere exept on CI
anyway.
The section in `CONTRIBUTING` about how to develop inside the
`node_modules` folder was removed, as the advice was a bit dated, and
wasn't specific to this project anyway.
5 years ago
|
|
|
package-lock.json
|
|
|
|
|
|
|
|
|
|
audit.json
|
|
|
|
|
|
|
|
|
|
app/bower_components
|
|
|
|
|
test/bower_components
|
|
|
|
|
package
|
|
|
|
|
.eslintcache
|
|
|
|
|
|
|
|
|
|
# IDEs
|
|
|
|
|
.idea
|
|
|
|
|
.vscode
|
|
|
|
|
.sublime-project
|
|
|
|
|
|
|
|
|
|
*.bak
|
|
|
|
|
|
|
|
|
|
# VIM
|
|
|
|
|
*.swp
|
|
|
|
|
*.swo
|
|
|
|
|
|
|
|
|
|
temp
|
|
|
|
|
.tmp
|
|
|
|
|
.sass-cache
|
|
|
|
|
.DS_Store
|
|
|
|
|
app/.DS_Store
|
|
|
|
|
|
|
|
|
|
storybook-build/
|
|
|
|
|
coverage/
|
|
|
|
|
jest-coverage/
|
|
|
|
|
dist
|
|
|
|
|
builds/
|
|
|
|
|
builds.zip
|
Add TypeScript migration dashboard (#13820)
As we convert parts of the codebase to TypeScript, we will want a way to
track progress. This commit adds a dashboard which displays all of the
files that we wish to convert to TypeScript and which files we've
already converted.
The list of all possible files to convert is predetermined by walking
the dependency graph of each entrypoint the build system uses to compile
the extension (the files that the entrypoint imports, the files that the
imports import, etc). The list should not need to be regenerated, but
you can do it by running:
yarn ts-migration:enumerate
The dashboard is implemented as a separate React app. The CircleCI
configuration has been updated so that when a new commit is pushed, the
React app is built and stored in the CircleCI artifacts. When a PR is
merged, the built files will be pushed to a separate repo whose sole
purpose is to serve the dashboard via GitHub Pages (this is the same
way that the Storybook works). All of the app code and script to build
the app are self-contained under
`development/ts-migration-dashboard`. To build this app yourself, you
can run:
yarn ts-migration:dashboard:build
or if you want to build automatically as you change files, run:
yarn ts-migration:dashboard:watch
Then open the following file in your browser (there is no server
component):
development/ts-migration-dashboard/build/index.html
Finally, although you shouldn't have to do this, to manually deploy the
dashboard once built, you can run:
git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git
yarn ts-migration:dashboard:deploy
2 years ago
|
|
|
development/ts-migration-dashboard/build
|
|
|
|
|
development/ts-migration-dashboard/intermediate
|
|
|
|
|
|
|
|
|
|
test-artifacts
|
|
|
|
|
test-builds
|
|
|
|
|
build-artifacts
|
|
|
|
|
|
|
|
|
|
#ignore css output and sourcemaps
|
|
|
|
|
ui/css/output/
|
|
|
|
|
|
|
|
|
|
notes.txt
|
|
|
|
|
|
|
|
|
|
.nyc_output
|
|
|
|
|
|
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
|
|
|
# MetaMask configuration
|
|
|
|
|
.metamaskrc
|
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
|
|
|
.metamaskprodrc
|
|
|
|
|
|
|
|
|
|
# TypeScript
|
|
|
|
|
tsout/
|
