[Bug] Sometimes Monaco loads extraLibs into models which causes IntelliSense to blow up

Reproducible in vscode.dev or in VS Code Desktop?

• Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

• Not reproducible in the monaco editor playground

Monaco Editor Playground Code

fetch('https://unpkg.com/@avst-types/runtime@0.14.1/index.d.ts')
    .then(res => res.text())
    .then(dts => {
        monaco.editor.create(document.getElementById('container'), {
            value: "export const initialize: InitializeFunction = async (event, context) => {\n\n}",
            language: 'typescript',
        });

        monaco.languages.typescript.typescriptDefaults.setExtraLibs([{
            content: dts,
            filePath: 'file:///node_modules/@types/avst-types__runtime/index.d.ts'
        }])

        // monaco.editor.createModel(dts, undefined, monaco.Uri.file('file:///node_modules/@types/avst-types__runtime/index.d.ts'))
    })

Actual Behavior

https://user-images.githubusercontent.com/9930079/145574787-3dcb1c66-e256-401f-a78e-2f3293b1d711.mov

As seen in the video. Initially IntelliSense works properly for context argument, inferring the type. But when I do SHIFT+F12 it breaks afterwards, the type then becomes any. It seems to be the issue of Monaco then going and loading this file of ambient types as a model (verified by debugging locally) and then TS is going to get confused because there are 2 identical files loaded both having the same types in it. If I go and dispose the model that Monaco created under the hood, then IntelliSense gets fixed.

If I replace loading those types using setExtraLibs, but creating the model for it instead in the first place, effectively preventing Monaco creating duplications, then it works correctly, but I no longer can do SHIFT+F12 to go to the reference.

Expected Behavior

IntelliSense not breaking when Monaco loads libs added via setExtraLibs into modules when it needs to.

Additional Context

When loading libs into Monaco, which is the correct API to do it these days, still using setExtraLibs or creating models for them? Apparently creating modes will break IntelliSense elsewhere (preventing SHIFT+F12 lookup).

[jonathan-codaio]

Thanks @alexdima ! Indeed, using Peek gives us a reliable repro finally.

I think the issue might simply be that the line that does the filtering is probably incorrect?

It’s currently:

const models = allModels.filter((uri) => !fileNameIsLib(uri)).map((uri) => uri.toString());

but it probably should be:

const models = allModels.map((uri) => uri.toString()).filter((uriStr) => !fileNameIsLib(uriStr));

What’s happening now is that what is passed to fileNameIsLib() is a Uri and not a string, so it always skips past this check:

https://github.com/microsoft/monaco-editor/blob/3ad48dbde4717be3249d7ac2b4451e271d77f07b/src/typescript/tsWorker.ts#L22

Though, I think there may not be an entry in libFileMap for these extra lib, either.

[jonathan-codaio]

We’ve been observing this exact same behavior for months, we hadn’t been able to look deeply into it until now and assumed it was a mistake in our usage, but it looks like it’s this same case, where something that we register only using addExtraLib in rare and seemingly non-deterministic cases gets converted into a redundant model. We are also seeing a model created for /lib.dom.d.ts even though we never touch anything related to this.

We still don’t have a way to repro this on demand, but have some good hints hear thanks to @ErkoKnoll 's report and will update if we’re able to come up with one.