Deprecate support for ECMAScript 5.1. #5128
Merged
Conversation
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
bf11623 to
4b42414
Compare
|
Looks like no one negatively reacted for 3 weeks, despite linking to this PR from all the usual places. @gzm0 Let's do it? |
gzm0
approved these changes
Mar 4, 2025
| @@ -87,6 +86,10 @@ final class ClosureLinkerBackend(config: LinkerBackendImpl.Config) | |||
| case ESVersion.ES2020 => ECMASCRIPT_2020 | |||
| case ESVersion.ES2021 => ECMASCRIPT_2021 | |||
|
|
|||
| // Test for ES5_1 without triggering the deprecation warning | |||
There was a problem hiding this comment.
This is so sad :((
Consider adding the full string ESVersion.ES5_1 in the comment for a bit better greppability.
There was a problem hiding this comment.
Good point. I also added a comment referring to here at the definition site of ES5_1.
That support is the biggest source of alternative code paths and polyfills in our codebase. The polyfills and other alternative implementations we need to support ES 5.1 include: * `Math.fround` to support `Float` operations (in `CoreJSLib`). * Other bit manipulation magic for floating-point numbers (in `FloatingPointBits`). * Using dynamic JS `Array`s instead of typed arrays for Scala `Array`s of primitive types. * Using custom Java `Map`s instead of `js.Map`. * Various implementations of math methods in `jl.Math` (although these may come back for a Wasm-only target, along with more of them). * Using run-time generated random property names instead of `Symbol`s. * Very complex code to handle surrogate pairs in `ju.regex.*`. * (Imperfect) desugaring of `...rest` parameters and `...spread` operators. Moreover, the ES 5.1 output does not even have exactly the same semantics as later versions: * JS classes are not true `class`es. Notably, that means they cannot extend native ES classes, and they do not inherit static members. * Top-level exports are declared as `var`s instead of `let`s. 10 years after the instruction of ECMAScript 2015, I believe it is time to deprecate the support for Es 5.1, so that we can eventually remove it.
4b42414 to
a4cdc6
8B62
f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
That support is the biggest source of alternative code paths and polyfills in our codebase.
The polyfills and other alternative implementations we need to support ES 5.1 include:
Math.froundto supportFloatoperations (inCoreJSLib).FloatingPointBits).Arrays instead of typed arrays for ScalaArrays of primitive types.Maps instead ofjs.Map.jl.Math(although these may come back for a Wasm-only target, along with more of them).Symbols.ju.regex.*....restparameters and...spreadoperators.Moreover, the ES 5.1 output does not even have exactly the same semantics as later versions:
classes. Notably, that means they cannot extend native ES classes, and they do not inherit static members.vars instead oflets.10 years after the instruction of ECMAScript 2015, I believe it is time to deprecate the support for Es 5.1, so that we can eventually remove it.
I did a simulation of all the things we could drop if we indeed removed support for ES 5.1 in the future. It is visible in #5129.