-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removed default options from some Babel plugins #2487
Removed default options from some Babel plugins #2487
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions. |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Hi @adityavohra7! We greatly appreciate the contribution. However, we generally like to opt for explicitness when specifying configurations so that it is easier to understand what we are configuring (and how). This also makes it difficult to upgrade package versions, because you're never sure if defaults have changed, etc. For right now, my stance is to leave this as-is. Do you have an objection? We eagerly look forward to contributions from you in the future. 😄 |
@Timer nope, no objections at all hehe. I was just trying to simplify the file, but I agree that being explicit about the config options makes things easier to track. Feel free to close the PR as un-merged! I do have two somewhat unrelated followup questions though:
|
We polyfill the usage of required helpers (e.g.
Fantastic question! I actually forgot why we did this myself, so I did some digging. See #332 for an explaination; effectively the default behavior is async -> generators -> regenerator. Declaring this like so allows us to go from async -> regenerator, bypassing some extra generated boilerplate (and thus shaving off some bytes!). |
Hmm isn't that what the // foo.js
export default class Foo {
constructor() {
this.foo = 42;
}
} Running
Running
I can see this being useful for reducing bloat if there are a lot of files with duplicated helpers inlined. I haven't done very many experiments comparing bundle sizes of large apps though so I can't say for sure :( |
IIRC babel-runtime/helpers/classCallCheck pulls in other polyfills that are unneeded, like Symbol. If you open a new issue we can talk about (and I would like to!). It's hard to keep track of here. 😄 I believe it is currently the case that every |
This PR removes default config options from some Babel plugins in
babel-preset-react-app
:regenerator
option forbabel-plugin-transform-runtime
(defaults totrue
).useBuiltIns
option forbabel-preset-env
(defaults tofalse
).I tested these changes by running
npm test
in thecreate-react-app
root dir (tests passed), and transpiling a simple file (verified that the output was the same before and after these changes).Here's the file I used:
BEFORE
$ NODE_ENV=production ./node_modules/.bin/babel src/foo.js
yields:$ NODE_ENV=development ./node_modules/.bin/babel src/foo.js
yields:$ NODE_ENV=test ./node_modules/.bin/babel src/foo.js
yields:AFTER
$ NODE_ENV=production ./node_modules/.bin/babel src/foo.js
yields:$ NODE_ENV=development ./node_modules/.bin/babel src/foo.js
yields:$ NODE_ENV=test ./node_modules/.bin/babel src/foo.js
yields:Outputs for all envs seem to be the same.