vscode should NOT use currently opened files as "the project"

[srcspider]

• VSCode Version: Code 1.16.0 (787b31c, 2017-09-06T16:19:37.192Z)
• OS Version: Linux x64 4.10.0-33-generic
• Extensions:

Extension	Author (truncated)	Version
theme-monokai-pro-vscode	mon	1.1.0

---

Steps to Reproduce:

1. given any project with tsconfig.json or .git on the root of the project
2. code -d <some/sub-directory>

Expected: There shouldn't be any difference to code -d .

Actual: Related features (in the example git or typescript) will not work; worse still for typescript they might cause incredibly poor experience since they give the impression "you have an error in your code" quite easily (which you don't!)

Fun fact if you do code -d <some-file> it actually works correctly! It's only directories it flops on.

Reproduces without extensions: Yes

---

VSCode git features, as well as far more annoyingly typescript features only really see the current opened file tree as "the project." This is troublesome because it means you are always forced to open the monolithic project for anything you do (unless you want those features to just break--for typescript that means errors everywhere as it's typings break).

Why open a sub-tree? There are many reasons, but the most important...

• great when working with workspaces or multiple monitors (different sections of interest on different workspaces or monitors)
• much easier to reason with when seeing a small subset (even if not split by business unit, almost all projects have a "src" section and the root is filled with garbage configuration files, or a folder where all the css is, different trees for server, client, whatnot etc)
• sometimes for various reasons such as some sort of refactoring of files around you need multiple file trees side by side

Desirable solution: search up until you find the key file (ie. .git or tsconfig.json)

Alternatively a way to artificially shrink the entire tree to just the desired tree (so a UI only fix) also works but is far more inconvenient since it means you cant just do code -d <some-folder> and expect it to just work (the confusion for anyone unaware also persists). Honestly even just having some "key" file to tell vscode "this is the project root" is a better alternative (for typescript you can just burrow "package.json" for this purpose, ie. search up until you hit "package.json").

Where it gets REALLY annoying

If you're not aware vscode is "confused" on the context of something like say "typescript," you can easily enter a state where the editor will complain about things, that actually it shouldn't complain at all.

In my case it was related to the .d.ts files feature. Since it couldn't read the tsconfig.json it couldnt figure out where declarations I wrote were. Writing these declarations is painful enough (with all the double-triple-standards of old/new/special-god-knows-what-rules) so having the editor report "I don't know where namespace is" but understand X and Y types declared in the same place as the namespace because the file was open in the same instance of the editor (I guess type symbols it can grab with out the tsconfig.json but namespaces are special?) makes for quite the painful experience.

As a new user to typescript I can say this particular editor issue (for the time you're unware it's the editors fault) paints the worst image possible for the language: one of a language with a lot of nitpicky issues where nothing anyone (including the documentation) works and where common sense is severely lacking.

And yes if you run tsc it works, but it's easy the editor confusion to send you into a loop where you add stuff to "fix it" (from your perspective) in the editor, that is clearly wrong, and hence break it in tsc, then you fix it in tsc, and now the editor complains again. Repeat (until you hopefully notice the disconnect between the two).

[mjbvz]

In general, I don't think that opening a subdirectory of a project should be treated the same as opening the project's root. VSCode is folder based, so the folder you open is the "project".

For TypeScript specifically, we'll always have to load the entire project for type checking purposes anyways. This however creates lots of confusion since often times the subfolder should not be treated as part of the larger project

I know this because we used to have the behavior you describe for locating tsconfig.json files. We disabled it because it was confusing and causing some terrible performance issues that we very difficult to track down. A few examples:

• Open a subdirectory and see globals suggested from the parent directory
• go to definition, symbol search, and many other operations would jump to files outside of your workspace. That was the correct behavior but also very confusing
• It turns out that many people had created tsconfig.json files in their home directory or in other top level directories that did not actually define a project. When we used to search up from the project root, we'd encounter one of these files and then try to load the user's entire home directory as a typescript project. This was far more common than you'd think

It sounds like you are using open folder to create multiple views of the same project. There are a few existing issues related to this #396, #2686, #367

[joaomoreno]

cc @bpasero

[mjbvz]

Closing out this issue with as-designed