Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build: transpile nullish operators and optional chaining #1497

Closed
smcclure15 opened this issue Nov 6, 2020 · 5 comments
Closed

Build: transpile nullish operators and optional chaining #1497

smcclure15 opened this issue Nov 6, 2020 · 5 comments
Labels
Category: Release Type: Meta Seek input from maintainers and contributors.

Comments

@smcclure15
Copy link
Member

What is the appetite to incorporate Babel transpiling of nullish coalescing operators (??) and optional chaining (?.) ?

@Krinkle Krinkle added Category: Release Type: Meta Seek input from maintainers and contributors. labels Nov 6, 2020
@Krinkle
Copy link
Member

Krinkle commented Nov 6, 2020

I'm somewhat leaning to removing Babel once we drop IE11 support and then use/require ES6 natively, and newer capabilities in sync with the browsers we support.

As such I'd slightly prefer not to emulate more syntax features. If some of these can be brought in via a conditional polyfil or utility function, though, that would be more appealing.

Having said that, I don't feel strongly about it 🙂 – It's just a general direction I have in mind at the moment.

@smcclure15
Copy link
Member Author

That sounds fair. Maybe I'm too eager to see old browsers drop off...
I figure if we can opportunistically write modern code today, we should, and let the transpile step support the oldest environment that we need to. Then when those drop, the code doesn't change - we just drop the transpilation. I do remain hesitant on experimental feature support - that can introduce some debt/instability that we don't need.

@Krinkle
Copy link
Member

Krinkle commented Nov 6, 2020

@smcclure15 I think we're in agreement. What I'm trying to avoid however is an indefinite hold-off where we're always waiting for the promise of a simpler stack that never arrives due to there always being another thing just over the horizon, so I'm trying to be a little bit more selective now so that we can start spending time on the other side of that horizon. Once there, we can adopt things as we see fit based on browser support, without that additional complexity.

@smcclure15
Copy link
Member Author

Sounds good, and thanks for taking the time to explain your rationale. I agree with the desire to avoid unnecessary churn and delay building up.

As a new member (thanks!), let me know if there’s anything I can do to support the effort on the 3.0 milestone, or it’s relevant timelines. I’ve recently indulged in dropping old browser support with my employer, and it’s been liberating from an infrastructure standpoint.

@Krinkle
Copy link
Member

Krinkle commented Nov 7, 2020

@smcclure15 Awesome. Couple of things to look at:

Also, if you like, feel free to join the Chat room.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Release Type: Meta Seek input from maintainers and contributors.
Development

No branches or pull requests

2 participants