m/metamask-extension
1
0
Fork 0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-29 07:16:36 +01:00
Code
ce257d8b70
metamask-extension/babel.config.js

17 lines
307 B
JavaScript
Raw Normal View History

Upgrade to Babel 7 (#6942) Babel 7 moved to a new configuration format, and they've scoped all of their packages under `@babel/`. This brings MetaMask in-line with dependencies we use that _already_ use Babel 7, and it eliminates a few unfortunate edge cases that can prevent dependencies from being correctly transpiled.
2019-08-02 17:47:20 +02:00
module.exports = function (api) {
@metamask/eslint config@5.0.0 (#10358) * @metamask/eslint-config@5.0.0 * Update eslintrc and prettierrc * yarn lint:fix
2021-02-04 19:15:23 +01:00
api.cache(false);
Upgrade to Babel 7 (#6942) Babel 7 moved to a new configuration format, and they've scoped all of their packages under `@babel/`. This brings MetaMask in-line with dependencies we use that _already_ use Babel 7, and it eliminates a few unfortunate edge cases that can prevent dependencies from being correctly transpiled.
2019-08-02 17:47:20 +02:00
return {
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-29 00:33:40 +02:00
parserOpts: {
strictMode: true,
},
Update Babel and dependencies (#15392)
2022-08-05 17:04:44 +02:00
targets: {
browsers: ['chrome >= 66', 'firefox >= 68'],
},
Upgrade to Babel 7 (#6942) Babel 7 moved to a new configuration format, and they've scoped all of their packages under `@babel/`. This brings MetaMask in-line with dependencies we use that _already_ use Babel 7, and it eliminates a few unfortunate edge cases that can prevent dependencies from being correctly transpiled.
2019-08-02 17:47:20 +02:00
presets: [
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-29 00:33:40 +02:00
'@babel/preset-typescript',
Update Babel and dependencies (#15392)
2022-08-05 17:04:44 +02:00
'@babel/preset-env',
Upgrade to Babel 7 (#6942) Babel 7 moved to a new configuration format, and they've scoped all of their packages under `@babel/`. This brings MetaMask in-line with dependencies we use that _already_ use Babel 7, and it eliminates a few unfortunate edge cases that can prevent dependencies from being correctly transpiled.
2019-08-02 17:47:20 +02:00
'@babel/preset-react',
],
@metamask/eslint config@5.0.0 (#10358) * @metamask/eslint-config@5.0.0 * Update eslintrc and prettierrc * yarn lint:fix
2021-02-04 19:15:23 +01:00
};
};
Copy Permalink