TheDude
/
ciphermask
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
A Metamask fork with Infura removed and default networks editable
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
14398 Commits
2 Branches
1 Tag
200 MiB
Tag: Branch: Tree: d0ed2c1afc
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'd0ed2c1afc'
${ noResults }
ciphermask/lavamoat/build-system/policy-override.json

109 lines
2.7 KiB
Raw Normal View History Unescape

Add Lavamoat to build system (#9939) * lavamoat - run build system in lavamoat * lavamoat/allow-scripts - add missing policy entry * update viz and lavvamoat * trim policy file * bump viz * prue policy override * regen policy file * Update package.json * Update package.json * Apply suggestions from code review Co-authored-by: kumavis <kumavis@users.noreply.github.com> * update policy, remove redundant patches * use yarn setup in CI Co-authored-by: kumavis <aaron@kumavis.me> Co-authored-by: kumavis <kumavis@users.noreply.github.com>
4 years ago
{
"resources": {
"@babel/core": {
"packages": {
"<root>": true,
"@babel/plugin-proposal-class-properties": true,
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
"@babel/plugin-proposal-nullish-coalescing-operator": true,
Add Lavamoat to build system (#9939) * lavamoat - run build system in lavamoat * lavamoat/allow-scripts - add missing policy entry * update viz and lavvamoat * trim policy file * bump viz * prue policy override * regen policy file * Update package.json * Update package.json * Apply suggestions from code review Co-authored-by: kumavis <kumavis@users.noreply.github.com> * update policy, remove redundant patches * use yarn setup in CI Co-authored-by: kumavis <aaron@kumavis.me> Co-authored-by: kumavis <kumavis@users.noreply.github.com>
4 years ago
"@babel/plugin-proposal-object-rest-spread": true,
"@babel/plugin-proposal-optional-chaining": true,
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
"@babel/plugin-transform-runtime": true,
"@babel/preset-env": true,
"@babel/preset-react": true,
"@babel/preset-typescript": true
Add Lavamoat to build system (#9939) * lavamoat - run build system in lavamoat * lavamoat/allow-scripts - add missing policy entry * update viz and lavvamoat * trim policy file * bump viz * prue policy override * regen policy file * Update package.json * Update package.json * Apply suggestions from code review Co-authored-by: kumavis <kumavis@users.noreply.github.com> * update policy, remove redundant patches * use yarn setup in CI Co-authored-by: kumavis <aaron@kumavis.me> Co-authored-by: kumavis <kumavis@users.noreply.github.com>
4 years ago
}
},
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
"@eslint/eslintrc": {
"packages": {
Refactor ESLint config (#13482) We would like to insert TypeScript into the ESLint configuration, and because of the way that the current config is organized, that is not easy to do. Most files are assumed to be files that are suited for running in a browser context. This isn't correct, as we should expect most files to work in a Node context instead. This is because all browser-based files will be run through a transpiler that is able to make use of Node-specific variables anyway. There are a couple of important ways we can categories files which our ESLint config should be capable of handling well: * Is the file a script or a module? In other words, does the file run procedurally or is the file intended to be brought into an existing file? * If the file is a module, does it use the CommonJS syntax (`require()`) or does it use the ES syntax (`import`/`export`)? When we introduce TypeScript, this set of questions will become: * Is the file a script or a module? * If the file is a module, is it a JavaScript module or a TypeScript module? * If the file is a JavaScript module, does it use the CommonJS syntax (`require()`) or does it use the ES syntax (`import`/`export`)? To represent these divisions, this commit removes global rules — so now all of the rules are kept in `overrides` for explicitness — and sets up rules for CommonJS- and ES-module-compatible files that intentionally do not overlap with each other. This way TypeScript (which has its own set of rules independent from JavaScript and therefore shouldn't overlap with the other rules either) can be easily added later. Finally, this commit splits up the ESLint config into separate files and adds documentation to each section. This way sets of rules which are connected to a particular plugin (`jsdoc`, `@babel`, etc.) can be easily understood instead of being obscured.
3 years ago
"<root>": 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
"@babel/eslint-parser": true,
"@babel/eslint-plugin": true,
"@metamask/eslint-config": true,
"@metamask/eslint-config-nodejs": true,
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
3 years ago
"@metamask/eslint-config-typescript": true,
"@typescript-eslint/eslint-plugin": 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
"eslint": true,
"eslint-config-prettier": true,
"eslint-plugin-import": true,
Add JSDoc ESLint rules (#12112) ESLint rules have been added to enforce our JSDoc conventions. These rules were introduced by updating `@metamask/eslint-config` to v9. Some of the rules have been disabled because the effort to fix all lint errors was too high. It might be easiest to enable these rules one directory at a time, or one rule at a time. Most of the changes in this PR were a result of running `yarn lint:fix`. There were a handful of manual changes that seemed obvious and simple to make. Anything beyond that and the rule was left disabled.
3 years ago
"eslint-plugin-jsdoc": 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
"eslint-plugin-node": true,
"eslint-plugin-prettier": true,
"eslint-plugin-react": true,
"eslint-plugin-react-hooks": true
}
},
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
3 years ago
"@typescript-eslint/eslint-plugin": {
"packages": {
"@typescript-eslint/experimental-utils": true,
"@typescript-eslint/scope-manager": true,
"debug": true,
"eslint": true,
"ignore": true,
"regexpp": true,
"semver": true,
"tsutils": true,
"typescript": true
}
},
"@typescript-eslint/experimental-utils": {
"builtin": {
"path": true
},
"packages": {
"@typescript-eslint/scope-manager": true,
"@typescript-eslint/types": true,
"eslint": true,
"eslint-scope": true,
"eslint-utils": true
}
},
"@typescript-eslint/scope-manager": {
"packages": {
"@typescript-eslint/types": true,
"@typescript-eslint/visitor-keys": true
}
},
"@typescript-eslint/visitor-keys": {
"packages": {
"eslint-visitor-keys": 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
"eslint-module-utils": {
"packages": {
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
3 years ago
"@babel/eslint-parser": true,
"@typescript-eslint/parser": true,
Implement Flask onboarding UI (#12745) * Added Flask Experimental Area warning to OnboardingV2 * Added first time flow Flask Experimental Area warning * Made both onboarding flows use one Experimental Area component * Fix comments in React divs * Fix unreachable code * Fix build lint problems * Changes after code review * Added guards around route constants imports * Code Review changes * Update ui/components/app/flask/experimental-area/index.scss Co-authored-by: George Marshall <george.marshall@consensys.net> * Code review changes * Fix lint * Update ui/components/app/flask/experimental-area/index.scss Co-authored-by: George Marshall <george.marshall@consensys.net> * Update ui/components/app/flask/experimental-area/index.scss Co-authored-by: George Marshall <george.marshall@consensys.net> * Update ui/components/app/flask/experimental-area/index.scss Co-authored-by: George Marshall <george.marshall@consensys.net> * Update ui/components/app/flask/experimental-area/index.scss Co-authored-by: George Marshall <george.marshall@consensys.net> * Update ui/components/app/flask/experimental-area/index.scss Co-authored-by: George Marshall <george.marshall@consensys.net> * fix lint Co-authored-by: George Marshall <george.marshall@consensys.net>
3 years ago
"eslint-import-resolver-node": true,
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
3 years ago
"eslint-import-resolver-typescript": 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
}
},
"module-deps": {
"packages": {
"loose-envify": true
}
},
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
3 years ago
"node-sass": {
"native": true
},
Add Lavamoat to build system (#9939) * lavamoat - run build system in lavamoat * lavamoat/allow-scripts - add missing policy entry * update viz and lavvamoat * trim policy file * bump viz * prue policy override * regen policy file * Update package.json * Update package.json * Apply suggestions from code review Co-authored-by: kumavis <kumavis@users.noreply.github.com> * update policy, remove redundant patches * use yarn setup in CI Co-authored-by: kumavis <aaron@kumavis.me> Co-authored-by: kumavis <kumavis@users.noreply.github.com>
4 years ago
"sass": {
"env": "unfrozen",
"builtin": {
"url": true
},
"globals": {
"Buffer": true
}
Add TypeScript to the linting process (#13495) This commit allows developers to write TypeScript files and lint them (either via a language server in their editor of choice or through the `yarn lint` command). The new TypeScript configuration as well as the updated ESLint configuration not only includes support for parsing TypeScript files, but also provides some compatibility between JavaScript and TypeScript. That is, it makes it possible for a TypeScript file that imports a JavaScript file or a JavaScript file that imports a TypeScript file to be linted. Note that this commit does not integrate TypeScript into the build system yet, so we cannot start converting files to TypeScript and pushing them to the repo until that final step is complete.
3 years ago
},
"tsutils": {
"packages": {
"typescript": true,
"tslib": true
}
},
"typescript": {
"globals": {
"globalThis": true
}
Add Lavamoat to build system (#9939) * lavamoat - run build system in lavamoat * lavamoat/allow-scripts - add missing policy entry * update viz and lavvamoat * trim policy file * bump viz * prue policy override * regen policy file * Update package.json * Update package.json * Apply suggestions from code review Co-authored-by: kumavis <kumavis@users.noreply.github.com> * update policy, remove redundant patches * use yarn setup in CI Co-authored-by: kumavis <aaron@kumavis.me> Co-authored-by: kumavis <kumavis@users.noreply.github.com>
4 years ago
}
}
}