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
Implement setClassMethods
assumption
#12407
Implement setClassMethods
assumption
#12407
Conversation
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/34911/ |
af2cd67
to
013d938
Compare
0ba8512
to
9b673e3
Compare
@@ -21,6 +21,8 @@ export default declare((api, options) => { | |||
|
|||
const { loose } = options; | |||
|
|||
const setClassMethods = options.loose || api.assumption("setClassMethods"); |
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.
Which option should have the precedence? loose
is set directly in the plugin, but assumption
is the new modern option.
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.
I think loose
should be prioritized. We can use api.assumption("setClassMethods");
as default value for loose
. So loose: false
can not be overridden by api.assumption("setClassMethods");
.
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.
Do we want some kind of warning somewhere if both are specified?
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 2a785bb:
|
013d938
to
a4f47b8
Compare
da76ea2
to
c12cc57
Compare
a4f47b8
to
bfa7eef
Compare
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.
at least this part of the implementation is straightforward, 👍
@@ -21,6 +21,8 @@ export default declare((api, options) => { | |||
|
|||
const { loose } = options; | |||
|
|||
const setClassMethods = options.loose ?? api.assumption("setClassMethods"); |
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.
Actually, can we flip this? Have api.assumption
return undefined
unless is explicitly specified, then default to loose
:
api.assumption("setClassMethods") ?? options.loose
I think the assumption should be the highest priority, and we fall back to the old loose flag if the assumption isn't set.
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.
The rationale for giving precedence to loose
is that, even if it's "older", it's closer to the plugin:
{
"assumptions": {
"noDocumentAll": false
},
"plugins": [
"@babel/proposal-nullish-coalescing-operator",
["@babel/proposal-optional-chaining", { "loose": true }]
]
}
I think that the most intuitive thing would be to respect loose
for @babel/proposal-optional-chaining
(and thus output == null
), because it's explicitly passed to that specific plugin.
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.
We can deprecate loose option in Babel 8 and rename loose in optional chaining to noDocumentAll. Otherwise it is unclear for users that loose is actually meant to override the noDocumentAll assumption.
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.
So the question is if the top level thing (assumptions) should override the one closer to a plugin.. well either way we should notify the user somehow right? We don't want to suggest that both should be on right?
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.
IMO @JLHwung In that case, it should go:~~
const setClassMethods = options.loose ?? api.assumption("setClassMethods"); | |
const setClassMethods = | |
options.setClassMethods ?? | |
api.assumption("setClassMethods") ?? | |
options.loose; |
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.
Half of the goal of the assumptions RFC is to centralise this kind of option rather than keeping it per-plugin, since (especially with class plugins) they have big cross-plugin implications.
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.
I agree that loose
is "closer" to the plugin, but the assumptions list is highly specific to transformer output. So I see it as being the higher precedence item.
Plus, I can see toggling certain assumptions on/off and using loose
at the same time. This would allow devs to override some of the parts of loose
, eg enabling classCallCheck
while otherwise outputting loose code.
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.
For backward compatibility to Babel < 7.13, we should check if api.assumption
is available.
It has been handled in https://github.com/babel/babel/pull/12219/files#diff-876e2533ff9db5901b423e389d5aee5275594e79da63f0cdc14c8ce62f90b468R31
c12cc57
to
8affe9b
Compare
0c915a5
to
f32c34e
Compare
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.
If transformClass is not public, we should eventually replace isLoose by assumptions.
- transform-classes
f32c34e
to
2a785bb
Compare
- `mutableTemplateObject` and `ignoreToPrimitiveHint` (#12408) - `setClassMethods` (#12407) - `setComputedProperties` (#12490) - `ignoreFunctionLength` (#12491) - `noDocumentAll` (#12481) - `iterableIsArray` and `arrayLikeIsIterable` (#12489) - `pureGetters` (#12504) - `skipForOfIteratorClosing` (#12496) - `objectRestNoSymbols`, `setSpreadProperties` and `pureGetters` (#12505) - `noNewArrows` (#12613, #12793) - `setPublicClassFields` and `privateFieldsAsProperties` (#12497) - `constantReexports` and `enumerableModuleMeta` (#12618) - `constantSuper`, `superIsCallableConstructor` and `noClassCalls` (#12726) Co-authored-by: Justin Ridgewell <justin@ridgewell.name> Co-authored-by: Huáng Jùnliàng <JLHwung@users.noreply.github.com>
- `mutableTemplateObject` and `ignoreToPrimitiveHint` (#12408) - `setClassMethods` (#12407) - `setComputedProperties` (#12490) - `ignoreFunctionLength` (#12491) - `noDocumentAll` (#12481) - `iterableIsArray` and `arrayLikeIsIterable` (#12489) - `pureGetters` (#12504) - `skipForOfIteratorClosing` (#12496) - `objectRestNoSymbols`, `setSpreadProperties` and `pureGetters` (#12505) - `noNewArrows` (#12613, #12793) - `setPublicClassFields` and `privateFieldsAsProperties` (#12497) - `constantReexports` and `enumerableModuleMeta` (#12618) - `constantSuper`, `superIsCallableConstructor` and `noClassCalls` (#12726) Co-authored-by: Justin Ridgewell <justin@ridgewell.name> Co-authored-by: Huáng Jùnliàng <JLHwung@users.noreply.github.com>
- `mutableTemplateObject` and `ignoreToPrimitiveHint` (#12408) - `setClassMethods` (#12407) - `setComputedProperties` (#12490) - `ignoreFunctionLength` (#12491) - `noDocumentAll` (#12481) - `iterableIsArray` and `arrayLikeIsIterable` (#12489) - `pureGetters` (#12504) - `skipForOfIteratorClosing` (#12496) - `objectRestNoSymbols`, `setSpreadProperties` and `pureGetters` (#12505) - `noNewArrows` (#12613, #12793) - `setPublicClassFields` and `privateFieldsAsProperties` (#12497) - `constantReexports` and `enumerableModuleMeta` (#12618) - `constantSuper`, `superIsCallableConstructor` and `noClassCalls` (#12726) Co-authored-by: Justin Ridgewell <justin@ridgewell.name> Co-authored-by: Huáng Jùnliàng <JLHwung@users.noreply.github.com>
Main PR: #12219
RFC: babel/rfcs#5
Affected plugins:
transform-classes