Skip to content
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

Conversation

nicolo-ribaudo
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo commented Nov 27, 2020

Q                       A
Minor: New Feature? Yes
Tests Added + Pass? Yes
License MIT

Main PR: #12219
RFC: babel/rfcs#5

Affected plugins:

  • transform-classes

@babel-bot
Copy link
Collaborator

babel-bot commented Nov 27, 2020

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/34911/

@@ -21,6 +21,8 @@ export default declare((api, options) => {

const { loose } = options;

const setClassMethods = options.loose || api.assumption("setClassMethods");
Copy link
Member Author

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.

Copy link
Contributor

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");.

Copy link
Member

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?

@codesandbox-ci
Copy link

codesandbox-ci bot commented Nov 27, 2020

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:

Sandbox Source
babel-repl-custom-plugin Configuration
babel-plugin-multi-config Configuration

Copy link
Member

@hzoo hzoo left a 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");
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Contributor

@ExE-Boss ExE-Boss Dec 7, 2020

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:~~

Suggested change
const setClassMethods = options.loose ?? api.assumption("setClassMethods");
const setClassMethods =
options.setClassMethods ??
api.assumption("setClassMethods") ??
options.loose;

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Contributor

@JLHwung JLHwung Dec 10, 2020

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

Copy link
Contributor

@JLHwung JLHwung left a 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
@nicolo-ribaudo nicolo-ribaudo changed the base branch from nicolo-ribaudo/assumptions to feat-7.13.0/babel-core-features December 11, 2020 19:15
@nicolo-ribaudo nicolo-ribaudo merged commit ee9deaa into babel:feat-7.13.0/babel-core-features Dec 11, 2020
@nicolo-ribaudo nicolo-ribaudo deleted the assumption/classes branch December 11, 2020 19:29
nicolo-ribaudo added a commit to nicolo-ribaudo/babel that referenced this pull request Jan 12, 2021
nicolo-ribaudo added a commit that referenced this pull request Jan 24, 2021
nicolo-ribaudo added a commit that referenced this pull request Jan 24, 2021
nicolo-ribaudo added a commit to nicolo-ribaudo/babel that referenced this pull request Feb 4, 2021
nicolo-ribaudo added a commit to nicolo-ribaudo/babel that referenced this pull request Feb 10, 2021
nicolo-ribaudo added a commit to nicolo-ribaudo/babel that referenced this pull request Feb 11, 2021
nicolo-ribaudo added a commit that referenced this pull request Feb 16, 2021
- `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>
nicolo-ribaudo added a commit that referenced this pull request Feb 16, 2021
- `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>
nicolo-ribaudo added a commit that referenced this pull request Feb 21, 2021
- `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>
@github-actions github-actions bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Mar 13, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: assumptions outdated A closed issue/PR that is archived due to age. Recommended to make a new issue PR: New Feature 🚀 A type of pull request used for our changelog categories Spec: Classes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants