tsserver keeps a lock on tsconfig.json file

[dbaeumer]

All the details are in microsoft/vscode#1032. Interesting comment is microsoft/vscode#1032 (comment)

[zhengbli]

After some investigation, I noticed the following:

1. Only the tsconfig.json of the first project of each window would be locked. If you open a file belonging to another project in the same window, that tsconfig.json file will not be locked;
2. The tsconfig.json will not be locked by CodeOSS, if I build it from source;
3. The tsconfig.json will not be locked by Sublime, using the same version of tsserver.js.

In addition, I didn't find in the tsserver code where config file is ever opened without closing. So is it possible that this is not caused by tsserver?

[dbaeumer]

We use Code or CodeOSS when built from source as a node execution environment since it is actually node plus chrome :-). That is why the look is help by that process. However @claycephas nicely traced it down to the Code executable running the tsserver. See this comment: microsoft/vscode#1032 (comment)

The interesting line is:

"C:\Program Files (x86)\Microsoft VS Code\Code.exe" "c:\Program Files (x86)\Microsoft VS Code\resources\app\extensions\typescript\out\utils\electronForkStart" "c:\Program Files (x86)\Microsoft VS Code\resources\app\extensions\typescript\server\typescript\lib\tsserver.js"

As you can see we launch code as a node environment and ask it to execute the tsserver.js

IMO the lock might not be tacken by a open / read / close. Could it be that the lock is because of watching the tsconfig.json file ?

[zhengbli]

Interestingly, in the latest vscode nightly build the locking seems to be gone. I am on the build of 2016-01-14T17:42:22.161Z, with the latest typescript sdk via typescript@next on npm. I tried to open several folders and none of them resulted in an item showing up in the handle result.

The watcher didn't hold handlers of the file though, I tried fs.watch on files directly in node commandline, and no handles showed up on handle command result. Even if it does, all tsconfig.json and source code files should be treated the same, not only the first tsconfig.json opened in the window being locked. No other files are locked including source code files.

@dbaeumer Can you confirm that the locking is fixed in the latest VSCode build? If not I'll keep investigating to seem what could go wrong.

[mhegazy]

@dbaeumer ,any news?

[dbaeumer]

As pointed out in previous comments the lock was taken by the tsserver. See comment #6337 (comment). According to @zhengbli the watching logic has been rewritten. If VSCode was used with typescript@next it could be that the problem is gone. But this can't be confirmed by me since the changed appeared in the tsserver.

[zhengbli]

Closed for now, as I found no locks using the tsserver in master. If there is a repro in the future, this issue can be reopened.

[dbaeumer]

@zhengbli : please see the comment microsoft/vscode#1032 (comment). There is again a nice trace that the tsserver holds the lock.

[zhengbli]

@dbaeumer Thanks for the reference. I also saw this lock happened when I was testing on 0.10.6. However it disappears now on recent nightly builds of VSCode with typescript@next. In addition, on the recent builds even when I set the typescript to 1.7.5 installed globally with npm, the lock still does not exist.

[dbaeumer]

@zhengbli here are steps that reproduce the problem in case you want to verify on 1.8.x:

• clone https://github.com/moostad/vscodeTypescriptAsync.git
• start VSCode
• open app.tsx
• reload window

Run handle tsconfig.json and see that the process holding the lock is running the tsserver

[zhengbli]

@dbaeumer I did the exact steps and handle showed "No matching handles found." I'm on the latest VSCode build, the commit is 11ab20. I'll try on several other machines to make sure.

I saw your VSCode version is 0.10.6, yes on that one I did see the handle being held, but not on the new nightly builds.