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
Improve output of super()
#16194
Improve output of super()
#16194
Conversation
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/56080/ |
...gin-transform-classes/test/fixtures/assumption-constantSuper/accessing-super-class/output.js
Show resolved
Hide resolved
@@ -274,6 +274,7 @@ module.exports = [ | |||
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 #2
This 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)