Add ways to scope access to proposed API

[Tyriar]

We have a problem currently that if a first party wants to use one of our "forever proposed APIs" like window.onDidWriteTerminalData, they need to be added to our enable proposed API list which could lead them to accidentally use other proposed API which is likely to change.

This proposal is about adding a new API type which is stable but not accessible to anyone but close friends because of various concerns we have in making the API public. This would help these trusted parties not accidentally jump on proposed API and also help the general public from not trying out these APIs, I still get the occasional issue every now about someone who has tried onDidWriteTerminalData and asking about it being stabilized.

[jrieken]

This proposal is about adding a new API type which is stable but not accessible to anyone but close friends because of various concerns we have in making the API public.

I think this is how much of our proposed API is actually being used. I am not a fan of adding a third mechanism of restricted API or so. It will complicate things IMO.

[mjbvz]

One idea we previously discussed was a vscode.never.d.ts that tracks apis that we never plan on finalizing

[Tyriar]

Sure it will complicate things a little more on our side but it will save first party extensions from mistakenly using proposed API and breaking as a result. I can see how it would be tough to avoid this if your project includes vscode.proposed.d.ts.

It is a bit of a shame to hear that onDidWriteTerminalData will be 'forever' proposed, I am using it in CI and would prefer to not opt into the proposed API in order to use it 😅

(Didnt realise this was an internal ticket, sorry)

[xiaoice]

use --enable-proposed-api vscode-samples.proposed-api-sample and enableProposedApi:true
window.onDidWriteTerminalData was not work，help me

Did you uninstall @types/vscode, install vscode-dts and run its tasks as defined in the documentation?

[jrieken]

Sure it will complicate things a little more on our side but it will save first party extensions

This is not just about complexity but also about not being able to always cleanly separate things between N vscode.xyz.d.ts-files. We have seen that in the past and taken pragmatic approaches but that won't work for another stable/permanent d.ts-file.

This would help these trusted parties not accidentally jump on proposed API and also help the general public from not trying out these APIs

This reminds me of something that has been discussed previously - instead of giving extensions access to all proposed API they should have access to individual proposals only. This will help us manage the list extensions with access to proposed API and prevent accidental/unwanted API usage.

[Tyriar]

👍 opting into only a single API (or list) would fix the problem as well.

[jrieken]

(exploring ideas for september)