Nightly-only experimental features · Issue #28152 · microsoft/TypeScript (original) (raw)
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.
- It's hard to get feedback about an implementation that's hard to npm install!
- The work is already done! And the longer that we put off merging it in, the more difficult it becomes later on.
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
npm install typescript@next
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.
Using private class fields requires opting in to the `--experimentalPrivateFields` flag. Note that this flag is only available in nightly releases, that its functionality may change, and that it may be removed entirely. Regardless, feedback from experimentation is appreciated
At which point users could update their tsconfig.json
{ "compilerOptions": { // ... "experimentalPrivateFields": true } // ... }
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 like
'--experimentalPrivateFields' is an experimental option that is only available on unstable nightly releases. To use it, you must install a nightly version of TypeScript via 'npm install typescript@next'.
Precedent
- IIRC @wycats mentioned that this is already something the Rust team does.
- Browsers like Chrome ship certain JavaScript features only in canary (nightly) builds, but users have to explicitly jump into their settings and turn it on.
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.