1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-22 18:00:18 +01:00
Commit Graph

9 Commits

Author SHA1 Message Date
Brad Decker
1db0ee87ec
Update Eslint and deps (#15293) 2022-07-26 13:10:51 -05:00
Mark Stacey
b68aee1bef
Migrate the build script to yargs (#14836)
The build script now uses `yargs` rather than `minimist`. The CLI is
now better documented, and we have additional validation for each
option.

A patch for `yargs` was required because it would blow up on the line
`Error.captureStackTrace`. For some reason when running under LavaMoat,
that property did not exist.

Closes #12766
2022-06-21 17:37:05 -02:30
kumavis
223124a561
lavamoat@6 - update to secure package naming (#14488) 2022-04-26 07:36:57 -10:00
Elliot Winkler
53006d4cf0
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
2022-03-28 16:33:40 -06:00
Elliot Winkler
4447727eb6
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.
2022-03-21 12:54:47 -06:00
Elliot Winkler
1e494f3004
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.
2022-02-28 10:42:09 -07:00
Mark Stacey
3732c5f71e
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.
2022-01-07 12:27:33 -03:30
Olaf Tomalka
70386726f6
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>
2021-12-01 17:53:30 +01:00
Erik Marks
d4c71b8683
Add per-build type LavaMoat policies (#12702)
This PR adds one LavaMoat background script policy or each build type. It also renames the build system policy directory from `node` to `build-system` to make its purpose more clear. Each build type has the original `policy-override.json` for `main` builds. The `.prettierignore` file has been updated to match the locations of the new auto-generated policy files.

We need to maintain separate policies for each build type because each type will produce different bundles with different internal and external modules.

Co-authored-by: Mark Stacey <markjstacey@gmail.com>
2021-11-15 14:23:46 -08:00