Repository navigation
[v8] Drop support for ES5 #9829
Description
Currently, we emit JS (both in the CDN bundles, as well as in the npm packages) that is ES5 (down to IE11) compatible.
In v8, we want to stop emitting ES5, and instead emit newer JS standard.
I would propose to emit ES2017. You can see a decent overview of new features here: https://en.wikipedia.org/wiki/ECMAScript_version_history#ES2017
ES2017 includes:
- basic ES6
- async/await
- [].includes()
- Object.values(), Object.entires(), object.getOwnPropertyDescriptors()
ES2018 added Promise.finally, which is nice but not so important for us I'd say.
ES 2019 added [].flat / [].flatMap(), and Object.fromEntries() (which again is nice, but nothing we use too much).
ES2020 is nice because it adds nullish coalescing and globalThis, but it is pretty recent ("just" 3 years old...)
This means that in v8, we will not ship any polyfills for stuff below ES2017. If you still need to support older browsers, you need to polyfill/transpile the SDK yourself (which most bundlers will do anyhow for you).
Open questions
- Should we target Es2017 or something else?
- Should we continue to provide ES5 CDN bundles?
- We started some work to have the loader detect ES6 support. Maybe we should revisit this and actually ship this? To avoid breaking loader users that still need ES5 support (for them, providing polyfills is harder than for npm users)
Metadata
Metadata
Assignees
Labels
Projects
- Status
Activity
AbhiPrasad commentedon Dec 14, 2023
I vote for es2017! Having
Object.values,includesandasync/awaitwill improve the bundle size situation a ton in our codebase.yonggwan commentedon Feb 23, 2024
please do not abandon ie11 😭
lforst commentedon Feb 23, 2024
@yonggwan 🥲 how are you using Sentry? Via the CDN bundle or the npm package?
build(bundles): Use ES2017 for bundles (drop ES5 support) (#10911)
timfish commentedon Mar 13, 2024
ES2018 includes
object rest/spread propertieswhich our node targets support as does every browser released since 2018. This has to be a good enough reason to choose ES2018 over ES2017?Optional chaining and nullish coalescing are ES2020 but Node v14.18 supports both of them so we can remove the polyfills entirely for
@sentry/node.s1gr1d commentedon Mar 13, 2024
@timfish Good point! We can base everything on ES2018 to also use the spread operator 👍🏻
timfish commentedon Mar 13, 2024
I just double checked this because I couldn't see any spread polyfills and...
"iterable spread" (ie.
[...args]) was ES2015/ES6 and ES2018 adds "object spread/rest" (const {...rest} = {...spread}).I guess if we didn't have polyfills we were leaving these down to typescript? Or they've already been deleted and I missed that?
mydea commentedon Mar 13, 2024
Maybe TS transpiles that based on the target, I'd say?
AbhiPrasad commentedon Mar 19, 2024
Update: after some discussion in slack we're going to make the default ES2018!
This makes the minimum browser versions now:
s1gr1d commentedon Mar 19, 2024
Promise.prototype.finally(which is included in ES2018) is Firefox 58 :)build(bundles): Use ES2018 for bundles (#11201)
build(bundles): Use ES2018 for bundles (#11201)
build(bundles): Use ES2018 for bundles (#11201)
build(bundles): Use ES2018 for bundles (getsentry#11201)