No type error indication on typescript example

[p-buddy]

Hello! Thank you for creating and maintaining this library.

I've successfully replicated the typescript example, but I notice both in my implementation and the hosted example type errors are not highlighted.

Specifically, the following code displays no errors:

const takesString = (x: string) => {};

takesString(0);

Screenshot (from hosted example):

However, a standard instance of monaco editor (instantiated via the "@monaco-editor/react" component) does highlight this error:

Screenshot:

Is this expected, and perhaps just a limitation of the typescript service? Or is this an error?

[p-buddy]

To follow up, I do find that this error is correctly highlighted in codingame's IDE.

screenshot:

Perhaps they are using the @codingame/monaco-vscode-standalone-typescript-language-features service to accomplish this?

[kaisalmen]

Hi @p-buddy interesting. Thanks for bringing this up. It should behave the same way.

[CGNonofr]

Btw, it works on https://monaco-vscode-api.netlify.app/, which also uses the typescript default extension

Perhaps they are using the @codingame/monaco-vscode-standalone-typescript-language-features service to accomplish this?

Yes we are, but just because enabling crossOriginIsolated wasn't an option

[CGNonofr]

Actually, it's because of those options:

    "typescript.tsserver.experimental.enableProjectDiagnostics": true,
    "typescript.tsserver.web.projectWideIntellisense.suppressSemanticErrors": false,

[CGNonofr]

Or maybe not 🤔

[p-buddy]

Thanks for the responses @kaisalmen and @CGNonofr ! That's very interesting / promising about https://monaco-vscode-api.netlify.app/ since it does in fact look like the standalone-typescript extension is NOT used in it (even though it is listed as a dependency): search-in-repo-for-standalone-typescript

With my limited knowledge, the only thing I can identify different between the two is that the demo uses the latest versions of those packages and corresponding @codingame/monaco-vscode-api (16.0.2), while my code and this repo's code is tied to version 15.0.3 of those packages.

I attempted to upgrade just the typescript extensions to 16.0.2 (and using npm overrides to keep their @codingame/monaco-vscode-api dependency at 15.0.3), but that actually fully broke things.

Let me know if you think I should try any other directions!

[kaisalmen]

@p-buddy you have to keep the @codingame/monaco-vscode-api on the same level otherwise hell breaks lose. There should be a console log warning now informing you of the mismatch. It was introduced for v12 or v13 (I don't remember exactly).

I need to investigate still. Will come back to you latest next week.

[kaisalmen]

@p-buddy and @CGNonofr even with the latest version on dev branch this is still reproducible. Sorry, I overlook this issue, but I now know why it is not working here but in the monaco-vscode-api demo. The file is not opened via vscode.workspace.openTextDocument and therefore not announced to the language service. It works in the AppPlayground and there this done as such: https://typefox.github.io/monaco-languageclient/ghp_appPlayground.html

[kaisalmen]

I will fix the TS example

[kaisalmen]

@CGNonofr and @p-buddy we need the InMemoryFileSystemProvider. I fixed this in June for the AppPlayground. The fix is on the latest dev commit. Will be on main later today.