#14583 broke the development build scripts (e.g. `yarn start`) by adding a positional argument to a package script (`build:dev`) that is used and passed positional arguments in the build script itself. This PR removes the positional argument from the `build:dev` script and `yarn start` now works again. In addition, the `--apply-lavamoat` flag is properly forwarded to child processes, which was not the case in the original implementation.
To test, `yarn start` should work and LavaMoat should _not_ be applied, in distinction to `yarn build:dev dev --apply-lavamoat=true`. Whether LavaMoat is applied can be determined by checking whether `Object.isFrozen(Object.prototype)` is `true` (with LavaMoat) or `false` (without LavaMoat).
Adds a new flag, `--apply-lavamoat`, to the main build script. The flag controls whether LavaMoat is actually applied to the output of the build process. The flag defaults to `true`, but we explicitly set it to `false` in the `start` package script. Meanwhile, the `start:lavamoat` script is modified such that it applies LavaMoat to the build output in development mode, but it no longer runs the build process itself under LavaMoat as there aren't very compelling reasons to do so.
This change is motivated by the fact that development builds do not have their own dedicated LavaMoat policies, which causes development builds to fail since #14537. The downside of this change is that LavaMoat-related failures will not be detected when running `yarn start`. @kumavis has plans for fixing this problem in a future major version of the `@lavamoat` suite.
* lavamoat - apply lavamoat protections to popup and notification
* build - enable lavamoat for home
* lavamoat - add missing ui overrides for react family
* deps/patches - patch zxcvbn for ses compat
* created new test for bip-44 snap test
* added driver.Key.SPACE to allow sending spacebar
* made changes to final result check
* fixed expected pk result to proper value
* fixed to use npm package instead of local
* removed comment
* removed const delay - not needed (lint error)
* Rename NotificationController to AnnouncementController
* Fix test
* Add test for missing NotificationController state
* Bump controllers
* Move test to correct file
* Rename config key
* Add migration 71 to list of migrations
* Fix selector after migration
* fix failed off chain tx mismatch with next confirmed transaction
* dont drop failed txs when tx in confirmed
* add comment for reassigning logic
* resolve change requests
The `parserOptions.sourceType` config option in `.eslintrc.js` is used
to distinguish files that use ESM imports vs. files that do not.
The `import` plugin, specifically the `import/ambiguous` rule behaves
differently depending on this value. If a file is marked with
`sourceType` of `"module"`, then this rule will attempt to ensure that
the file does indeed have ESM imports and/or exports; otherwise it does
nothing.
In other words, files that use CJS imports are *not* "modules" according
to this setting, and therefore should not be marked with a `sourceType`
of `"module"`. This means we do not have to turn off the
`import/ambiguous` rule, as it will no longer trip up on these types of
files.
Daniel
Brad Decker
ryanml
Erik Marks
Frederik Bolding
hilvmason
kumavis
Alex Donesky
Shane
MetaMask Bot
Thomas Huang
George Marshall
Guillaume Roux
David Walsh
Bowen Sanders
Hennadii Ivtushok
amerkadicE
Dan J Miller
MetaMask Bot
Ariella Vu
ricky
Elliot Winkler