(bug) Closed document ownership not transferred back to the filesystem about typescript-language-server HOT 5 OPEN

Are you saying that prior to running any ApplyWorkspaceEdit, the client must send didOpen (and then send a didChange explicitly as well).

That is the way I understood the spec.

If a file is closed
and a WorkspaceEdit comes in for the file,
the client would first need to open that file (that should send a didOpen notification)
and then apply the edits (that should send a didChange notification).

from typescript-language-server.

Spec talks about ownership and that the editor has to send didOpen to take ownership of the document before it can change it:

• https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didChange
• https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didOpen

from typescript-language-server.

I'm a bit confused. I've read those parts of the spec, but I don't know if it explains the inconsistent behavior that occurs when import1.ts has been open - and then closed - on the client vs. when it never has been opened on the client at all.

When it's never been opened at all, the imports get updated correctly. However when it's been opened and then closed, suddenly things do not work.

Are you saying that prior to running any ApplyWorkspaceEdit, the client must send didOpen (and then send a didChange explicitly as well). I'm struggling to understand how that would work for situations where a file on the filesystem has been edited programmatically, through any other means.

from typescript-language-server.

It feels like there is some distinction being made for files that have programmatic edits triggered by an ApplyWorkspaceEdit, versus any other file that was edited programmatically.

Here's an example:

• I create a file in my editor import3.ts and save it with the contents:

import { a } from './export';

• I then close it. I then open it in vi and change the contents to:

import { a } from './mangledimportpath.xyz'

• Since there is no file open in vscode - there is not a didChange notification made to tsserver - it just has file watchers running.
• I then rename export.ts to export2.ts
• In vscode, tsserver sends a getEditsForFileRename and knows that import3.ts has been updated, no longer imports from export.ts, and thus, it doesn't include import3.ts in its list of file changes.

The only difference here between the above edit of a closed file, and this edit of a closed file, is that one was initiated by an ApplyWorkspaceEdit and one was not. So is the language server tracking the WorkspaceEdits it proposes to see if the client actually applies them or not?

from typescript-language-server.

Here's an example:

I've tried it here and it worked fine for me.

If you want me to have a look into it then please:

• provide a repo that reproduces this simplified case
• set initializationOptions.tsserver.logVerbosity to verbose and provide the tsserver log that is created in the .log directory after reproducing the issue

from typescript-language-server.