Remove BABEL_TYPES_8_BREAKING flag and enable it by default#16817
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/57948 |
| ), | ||
| ), | ||
| default: !process.env.BABEL_TYPES_8_BREAKING ? [] : undefined, | ||
| default: !process.env.BABEL_8_BREAKING ? [] : undefined, |
There was a problem hiding this comment.
Can we warn if somebody uses the old one? Like, with this at the beginning of the file:
if (!process.env.BABEL_8_BREAKING && process.env.BABEL_TYPES_8_BREAKING) {
console.warn("BABEL_TYPES_8_BREAKING is not supported anymore. Use the latest Babel 8.0.0 pre-release instead!");
}| if (!process.env.BABEL_8_BREAKING) { | ||
| return assertValueType("string"); | ||
| } |
There was a problem hiding this comment.
Lets use a if...else, so that the else block can be removed at build time.
| assertValueType("string"), | ||
| Object.assign( | ||
| function (node, key, val) { | ||
| const invalid = /[^gimsuy]/.exec(val); |
There was a problem hiding this comment.
Something seems wrong here, at least has v?
There was a problem hiding this comment.
nicolo-ribaudo
left a comment
There was a problem hiding this comment.
Do you think it's fine to merge this in a patch release? People shouldn't rely on this flag on production anyway.
|
Actually, looking at https://github.com/search?q=BABEL_TYPES_8_BREAKING&type=code there is significant usage of this flag, even set to @liuxingbaoyu Would it be ok for what we need to do |
It's fine for me. Also it seems that |
|
It occurs to me that this still can't be avoided #16097. 😭 |
cd8cf89 to
edc16e4
Compare
BABEL_TYPES_8_BREAKING to BABEL_8_BREAKINGBABEL_TYPES_8_BREAKING flag and enable it by default
| assertions: { | ||
| deprecated: true, | ||
| optional: true, | ||
| validate: chain( | ||
| assertValueType("array"), | ||
| assertEach(assertNodeType("ImportAttribute")), | ||
| ), | ||
| }, |
There was a problem hiding this comment.
I reverted the changes from a previous PR to this and added deprecated, because otherwise any would break our type system.
e5d237c to
ef6c6c8
Compare
Uh oh!
There was an error while loading. Please reload this page.