m/metamask-extension
1
0
Fork 0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-23 02:10:12 +01:00
Code
5fa841aa46
metamask-extension/.prettierignore

15 lines
266 B
Plaintext
Raw Normal View History

Use `prettier` for JSON linting (#9396) Instead of using `eslint-plugin-json` for linting JSON files, `prettier` is now used. `prettier` is capable of detecting and correcting more problems than `eslint-plugin-json` can, such as indentation. All JSON files have been run through `prettier`. The changes are all superficial.
2020-09-11 15:57:39 +02:00
node_modules/**
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 23:23:46 +01:00
lavamoat/**/policy.json
Use `prettier` for JSON linting (#9396) Instead of using `eslint-plugin-json` for linting JSON files, `prettier` is now used. `prettier` is capable of detecting and correcting more problems than `eslint-plugin-json` can, such as indentation. All JSON files have been run through `prettier`. The changes are all superficial.
2020-09-11 15:57:39 +02:00
dist/**
builds/**
test-*/**
coverage/
Add jest-coverage/ to prettierignore (#10865)
2021-04-09 20:16:19 +02:00
jest-coverage/
Use `prettier` for JSON linting (#9396) Instead of using `eslint-plugin-json` for linting JSON files, `prettier` is now used. `prettier` is capable of detecting and correcting more problems than `eslint-plugin-json` can, such as indentation. All JSON files have been run through `prettier`. The changes are all superficial.
2020-09-11 15:57:39 +02:00
app/vendor/**
make gas edit tooltips use Tooltip (#9434)
2020-09-18 00:05:31 +02:00
.nyc_output/**
.vscode/**
[RFC] add prettier to eslint (#8595)
2020-11-03 00:41:28 +01:00
test/e2e/send-eth-with-private-key-test/**
improve design system scss (#10193)
2021-01-19 17:30:29 +01:00
*.scss
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 18:42:09 +01:00
development/chromereload.js
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
2022-08-09 22:16:08 +02:00
development/ts-migration-dashboard/filesToConvert.json
Copy Permalink