Skip to content

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/


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

@nicolo-ribaudo nicolo-ribaudo force-pushed the nicolo-ribaudo/assumptions branch 2 times, most recently from da76ea2 to c12cc57 Compare November 27, 2020 15:52
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, 👍


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

@nicolo-ribaudo nicolo-ribaudo Dec 5, 2020

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.

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 <[email protected]>
Co-authored-by: Huáng Jùnliàng <[email protected]>
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 <[email protected]>
Co-authored-by: Huáng Jùnliàng <[email protected]>
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 <[email protected]>
Co-authored-by: Huáng Jùnliàng <[email protected]>
@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.

7 participants