-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Nightly-only experimental features #28152
Comments
Do you plan on just disabling certain compilerOptions in stable releases or do you want to entirely remove the feature's code from the package? |
cc @Neuroboy23 |
This sounds like a great plan for early, experimental features which have gotten insufficient community feedback. Do you have any thoughts on how to assess which proposals should be treated as such? In general, I'd like to collect this input before moving proposals to Stage 3 at TC39. I wonder if this flag system would be useful for certain Stage 2 proposals. |
This idea came about from a discussion I had with @wycats back in July when we discussed how Rust ships experimental features without the team feeling "locked in" if too many people take a dependency on it. If I'm suggesting anything drastically different from what we discussed, hopefully he can correct me.
Motivation
For some background, we've been helping a few of our friends at Bloomberg to implement ECMA262's private class fields proposal within the TypeScript compiler; however, given the sort of contentious feedback that we've seen on the proposal's repository, we'd like to first elicit feedback from the broader community around use-cases and general opinions around the private class fields proposal. But there's two problems with that.
How do we solve the above two problems without risking a change of course from ECMA262's proposal?
Not the solution
Release with
--experimentalPrivateFields
In the last ~2 years or so, we've been extremely wary of adding any flags to control experimental features, specifically because we know that
--experimentalDecorators
became a widespread hard dependency in the community in which the implementation deviated from the current ECMAScript proposal. How can you reasonably ever kill something like--experimentalPrivateFields
if it ever landed in a stable release?Maybe the solution is to never land it in a stable release!
Maybe the solution
Release only nightlies with
--experimentalPrivateFields
TypeScript publishes a nightly release every, uh, I guess night depending on your time zone 🌏🌍🌎. Typically these releases are a good test bed for early adopters who want the latest and greatest features and bug fixes. Much of the time, they're purely for experimenting with features early on. General stability of the release is implied (i.e. usable with no major crashes or anything) but features themselves are prone to changing.
The idea here would be that if you wanted to actually use the private class fields proposal, you would have to get off of a stable version of TypeScript and then opt in with the flag.
So a user would have to run
to get the appropriate nightly release. At this point, trying to compile code with a private class field would result in the following error message on the declaration.
At which point users could update their
tsconfig.json
Completely error in non-nightly releases
Under a non-nightly release (insiders, rc, latest, whatever's not
next
/dev
), TypeScript should completely refuse to recognize the--experimentalPrivateFields
option. It is an error to utilize it and it should prevent compilation from succeeding. Using it might result in an error message likePrecedent
Other considerations
This functionality might need some minimal changes to our testing infrastructure, and appropriate feature gating utilities; however, I'm not convinced this will come up often enough that we will need to build up any heavy-weight abstractions.
CC: @robpalme @joeywatts @mheiber
The text was updated successfully, but these errors were encountered: