If @orta has nothing against it, I think this feature is a nice candidate for being contributed by the community.
If you submit a PR, I'd be more than happy to help you getting it merged!

I could take a stab at it - since I've already gone into the rabbit hole of figuring some of this stuff for hacking purposes.

There are some things that I still don't get and could use some clarification on them before I start coding things. Could the TS language stuff be unified more with what is implemented in the VScode repository? I went spelunking into both repositories (VScode and monaco-typescript), trying to figure out how they relate, on what data types they operate and how do they implement certain things. The overlap is big but so is the divergence between them. Is this mostly a historical reason? And VScode having to handle compatibility with all (most?) TS versions? Is there anything else at play here?

Any particular gotchas that you could think of at this stage already? Something I should be aware of? Is there any test suite validating the functionality beyond what can be found here and in the monaco-typescript repository? In those two there are not a lot of tests so I'm a little bit worried that I could unintentionally break some stuff due to lack of experience with those projects.

Both monaco-typescript and typescript-languge-features (vscode) are two completely separate implementations of a binding for a TS TSServer to the Monaco or VS Code APIs. They both have overlap but generally the fancy features get shipped to vscode as the TS + VS team build out a feature and then if it makes sense for web I (or a community member) sends a PR to monaco-typescript

There's probably only 2 params because that's how many params were on that function back when the feature was added, monaco-typescript is probably just ignoring all the newer params. I don't think there's a systemic constraint. You're welcome to add it 👍🏻

From what I've seen VScode is currently implementing completionItemProvider using the TSServer API instead of the Language Service API. Would it be possible to rewrite it to the latter (I could potentially try to dig into this)? That way rewriting the one in the monaco-typescript would get easier, and any future syncs would also be easier. I know that VScode has to support more than a single TS version so maybe there is a reason why this has not been done yet - or is it maybe just a legacy issue at this point in time?

Either way - I would love to contribute this to monaco-typescript but the docs are very sparse about a lot of things. Would anybody here be up for providing some mentoring help if I stumble upon issues that I wouldn't know how to resolve?

For instance, at the moment, in my monkey-patched "fork" I had to:

• store access to the model so it would be used within resolveCompletionItem because this function doesn't receive it as an argument. The model was needed for me to convert the retrieved textChanges to the additionalTextEdits (had to convert a text span to a Range)
• replace resolved node_modules paths with module names because the tryGetModuleNameAsNodeModule relies on the fs calls whereas the fs mock is not provided to TypeScript by default.

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!