Nightly-only experimental features

[DanielRosenwasser]

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.

1. It's hard to get feedback about an implementation that's hard to npm install!
2. 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.

CC: @robpalme @joeywatts @mheiber

[ajafff]

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?
Simply disabling the option seems to be less effort. In addition it allows 3rd party tools to use the relevant APIs when operating on a project that uses these nightly features.
Will there be a way to query which compilerOptions are currently available (or which ones are forbidden nighly options)?

[mheiber]

cc @Neuroboy23

[littledan]

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.

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.