[babel 8] ObjectTypeAnnotation fields must always be arrays#14465
Merged
Conversation
JLHwung
approved these changes
Apr 21, 2022
Contributor
JLHwung
left a comment
JLHwung
left a comment
There was a problem hiding this comment.
The changes look good to me. BABEL_TYPES_8_BREAKING is superseded by BABEL_8_BREAKING, so the latter should be good to go.
danez
force-pushed
the
danez-objecttypeannotation-fields
branch
from
82ad2f2 to
5d5202f
Compare
Member
Author
|
Ok, I put all the changes behind the flag. Is there a document where all breaking changes/migrations steps are recorded? |
…are always present BREAKING CHANGE: The 2., 3., and 4. parameter to the builder for `ObjectTypeAnnotation` do not accept null anymore. Use undefined.
danez
force-pushed
the
danez-objecttypeannotation-fields
branch
from
5d5202f to
4882ccc
Compare
Contributor
Yes, see #10746. |
existentialism
approved these changes
Apr 22, 2022
nicolo-ribaudo
changed the title
ObjectTypeAnnotation are always presentObjectTypeAnnotation fields must always be arrays
Member
|
@danez Even if something is not tracked in this issue (for example, this PR is a very small breaking change), we are marking all these changes with the same label so that we can go through them when preparing Babel 8. |
Member
Author
|
Ok cool. |
github-actions
Bot
added
the
outdated
JLHwung
added
PR: Breaking Change 💥
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The fields
indexers,callProperties, andinternalSlotsin the nodeObjectTypeAnnotationare currently marked as optional. This is correct for the builder, they should be optional there.For the TS types, this is not quite correct, because the babel parser always initializes these fields with empty arrays (https://github.com/babel/babel/blob/main/packages/babel-parser/src/plugins/flow/index.js#L1085-L1088).
The only way to set these fields to null is with the builder currently.
The change here is to not mark these fields as optional but instead provide an empty array as a default value. This way the builder still has these params as optional, but cannot be set to
nullanymore.The Typescript types on the other hand now do not mark these fields as optional which is correct, as they are always an array, even if it might be empty.
Do you think this is a reasonable change?
Now, is this breaking? Only the builder might be considered as a breaking change, as it does not allownullanymore for these fields (see change generator tests). If you think this is breaking enough I could move that behind the BABEL8 flag. Please let me know.After thinking about this a little more I now think this should be considered breaking. Which Flag should I use?
BABEL_TYPES_8_BREAKINGorBABEL_8_BREAKING