Improve output of super()#16194
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/56080/ |
| "no-func-assign": "off", | ||
| "import/no-extraneous-dependencies": "off", | ||
| "import/no-unresolved": "off", | ||
| "@typescript-eslint/prefer-optional-chain": "off", |
There was a problem hiding this comment.
@JoshuaKGoldberg If we set parserOptions.ecmaVersion to 5, will typescript-eslint respect the ecmaVersion and automatically turn off this rule?
There was a problem hiding this comment.
Interesting idea! No, rules in the preset configs won't be configured differently based on your parserOptions. I don't believe ESLint configs can be dynamic in this way. At least legacy ones aren't, and we haven't added official support for flat configs yet.
There was a problem hiding this comment.
@JoshuaKGoldberg Thank you! I think this is not a very common use case, since most TS projects will use tsc to transpile ts sources anyway.
@liuxingbaoyu Can we set parserOptions.ecmaVersion to 5 for helpers? So the linter should throw if there are non-ES5 codes.
There was a problem hiding this comment.
Parsing error: ImportDeclaration should appear when the mode is ES6 and in the module context.
I tried it and it didn't work.
Our current ts source actually has some es6 syntax such as trailingComma handled by terser which I think is fine.
I have now unified js with ts and explicitly specified terser as es5.
5032da2 to
a0888ba
Compare
|
Thanks for the tag! Now that we have released v7.23.7, I removed it as it should be included in the next release no later than later. :) |
|
Luckily github fixed their CI issue, this PR has test262 failure, I will fix it. |
|
When compiling this code: class A extends B {
constructor(arg1, arg2, arg3) {
super(arg1, arg2);
this.arg3 = arg3;
}
}targeting IE11, and manually replacing helper names with one-char variables when minifing, the output size is:
The old code is slightly faster in some very old browsers when compiling implicit constructors, because we pass |
|
Now we avoid a function call/new closure, hoping that this can offset performance changes. : :) |
|
I'll avoid the |
|
Yeah, due to the regression fix #16199, we are enough to release a patch version. : :) |
|
Hi, could this change have caused a regression in output size? Home Assistant is seeing a hefty 4% bundle size increase from 7.23.7 to 7.23.8 (home-assistant/frontend#19368). Looking at the release notes, this PR seems like the only viable culprit. |
|
Took a deeper look and it seems the bundle is no longer using |
|
The purpose of this PR is to reduce the output size, but it may cause the size to increase when users use the new I noticed home-assistant/frontend@ |
|
Yes, I noticed |
Fixes #1, Fixes #2This is a small change, and if we can merge it before the next release, we won't need to add a
new-version-checklist. :) (Some of my other PRs are a bit troublesome to rebase)