Monolithic structure, multiple project settings

[thetrompf]

I was wondering if it is possible for VSCode to pick up on multiple .vscode/settings.json

For instance if you are working in an monolithic environment with multiple smaller projects inside it, and each have their own .vscode/settings.json.
Can VSCode pickup on that, and apply the settings from the smaller projects .vscode/settings.json to their subtree and descendant files?

monolithic-project/
├── small-project1/
│   ├── .vsocde
│   │   └── settings.json
│   └── src/
│       └── index.ts
└── small-project2/
    ├── .vsocde
    │   └── settings.json
    └── src/
        └── index.ts              

Wanted effect:
monolithic-project/small-project1/.vscode/settings.json applies to monolithic-project/small-project1 and all descendant files.
monolithic-project/small-project2/.vscode/settings.json applies to monolithic-project/small-project2 and all descendant files.

[sandy081]

Supporting folder settings at any level is a good idea and is similar to editor config.

FYI Currently we are working on a multi root workspace where you can have multiple root folders. In this case settings under each root folder are applied to the resources under the respective folder (just as you mentioned). But all such folders should be root folders (small-project1, small-project2). This feature is available only in insiders. See #28344 for more details.

Please close this request, if multi root workspaces full fill your requirements

[thetrompf]

Thank for the reply, I am aware of the progress in this area, but if you have a monolithic repo with multiple small projects inside that lives on the different levels on the filesystem and you add the root of the repo as a root in a multi root workspace, and then you add folders from within the project root to appear at top level, it will possibly break the experience of quick open, where the same file would appear multiple times, the same goes for search, or I would have to manually exclude the folders that has been added as a workspace roots from the project root's file system. I think the experience would be a lot nicer if VSCode could handle multiple. vscode roots and make them apply to their respective sub trees. It would really shine if it could pick up on launch.json as well so I could choose the list of available launch profiles based on the active file in the editor.

On Mon, Aug 21, 2017, 4:45 PM Sandeep Somavarapu ***@***.***> wrote: Supporting folder settings at any level is a good idea and is similar to editor config. FYI Currently we are working on a multi root workspace where you can have multiple root folders. In this case settings under each root folder are applied to the resources under the respective folder (just as you mentioned). But all such folders should be root folders (small-project1, small-project2). This feature is available only in insiders. See #28344 <#28344> for more details. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32693 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABXSZo-X_5X-4cbuz5TDVua3vLeUnfREks5saZf_gaJpZM4O50vl> .

-- Med venlig hilsen / Best regards Brian K. Christensen

[DanTup]

I raised a case that I think covers this (but also a bit more) at #45399. This extends to more than just settings, but also launch configs/etc.

[thetrompf]

You're right it just extends to multiple .vscode directories. Settings, launch, tasks and etc.

[shridharkalagi]

I have landed in a similar situation. Is this resolved in the latest version?

[thetrompf]

Unfortunately is still experience exactly the same as stated in the issue description. Med venlig hilsen / Best regards Brian Kejlberg man. 21. jan. 2019 12.07 skrev Shridhar Kalagi <notifications@github.com>:

…

I have landed in a similar situation. Is this resolved in the latest version? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32693 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABXSZkEZtHKYnFb_u4V2HUk-cFnRWYYvks5vFZ9ggaJpZM4O50vl> .

[shridharkalagi]

Is this in the backlog of issues to be fixed? Any workaround till then?

[xujintao]

@DanTup
after #45399 then #45470
So, do vscode support mono or not? if not, which issue should be followed?

[DanTup]

@xujintao it depends a lot on your project structure and language. For Dart/Flutter, it's a little wonky without #45470, but we have made some improvements to find our own project roots instead of using multi-root workspaces.

[memark]

Any update on this? Still would be a really helpful feature!

[scgbear]

Internal Tracking

devdivcsef 412378

[hyrious]

I also miss extensions being local to projects

@superherointj You can already do that in workspace, just goto the extension page and click "Enable (Workspace)"

[mathiasayivor]

So, it's still 2023 and this feature is still pending for an editor, like vs code? Wow. Just wow.

[thetrompf]

You could ask for a refund.

[adonig]

Can someone please ask ChatGPT to fix this issue?

[superherointj]

Please avoid noise (push back and joke). It notifies subscribers. Like this is important. And actually isn't.
Now this message itself is going to create more notifications. Hopefully the last one of noise? Please don't answer.

[starball5]

Meta notes:

Possibly/loosely related:

• Add ability to extend from other settings files #15909
• Allow folder settings to cascade / be inherited #111884 (which I'm personally confused as to why it was closed as a duplicate of this one, since the particular motivating example here seems like something that multi-root workspaces are fairly suitable for, whereas multi-root workspaces do not generalize as a solution for 111884)

Related (some loosely) on Stack Overflow:

• Monorepo - Multiple .vscode settings
• Is it possible to have multiple projects in a single VS Code workspace?
• local settings.json does not override global settings.json from my understanding is really more related to Allow folder settings to cascade / be inherited #111884 (the one that got closed as a dup of this issue ticket)

[datvm]

I want to specify another usecase for this is the glob based properties like Readonly. For example, I want all js/** files of all projects in a folder only to be readonly (because they are generated by TypeScript).

Now my folder would look like this:

Root
|-- Project 1
    |-- js <-- files in this folder should be readonly
|-- Project 2
    |-- js <-- files in this folder should be readonly
|-- .vscode <-- config file in here

When working, I would open Project1 or Project2 folders, not Root. So in this case, I would like VS Code to look up the parent folders for a .vscode for settings. The blob should also be applied to that project folder, not Root btw.

[eliliam]

This has been open for 6 years now, can we please get some support here? Even if it's only in the insiders or nightly builds to start. This is a crucial feature that nearly every other tool supports.

VS Code is the foundation for most web development environments and is used by teams across many types of projects. Having support for monorepos and opening subdirectories instead of the root of the monorepo(which often is very large and uses more resources than you need) would allow for a truly amazing experience standardizing settings across a monorepo for teams of developers.

Would something like this be possible do do in an extension if Microsoft doesn't want to add this for whatever reason?

[georglauterbach]

This is also a blocker for Rust projects where a workspace is used and some workspace members have different compilation targets. Setting "rust-analyzer.cargo.target": "riscv64gc-unknown-none-elf" in the global settings.json is not possible because it overwrites the target for all workspace members..

[photex]

The vscode multi-root workspaces seem to achieve only the most minimal parts needed of a proper workspace; in which you combine multiple paths and give them a single governing settings object.
What would be the most useful and would be wonderful to see instead, is a clear declaration of paths (including folder exclusions) and the ability to override settings based on these root folders in addition to common workspace level settings ideally in the single root level *.code-workspace (but I'd be ok using multiple .vscode subdirectories too).

---

I'll give an example of why this is useful for myself and my team. I work in automotive and a lot of our code that deals with various CAN vehicle protocols have some associated test suites that exercise the state machines we either implement or interact with.
We run these tests on the desktop, but they're using libraries that are also built into the application that we flash to the devices. We also have some desktop tools that listen to CAN messages and reports diagnostics and even some HIL tests that we can run using cmake workflow presets.

To facilitate this a lot of code is shared and it simply isn't an option to break it into a bunch of tiny repos with separate builds. The workflow we have with CMake, Cmake presets and our toolchains all living in a single cohesive depot workspace saves us enormous amounts of time and energy. And probably the best part, is that the opportunity cost of properly modularizing code is almost null.

Our depot is a single Cmake build which targets embedded and desktop builds using an extensive library of cmake presets which provide concrete toolchain configurations and properly configure helpful things like build caches.
Some subfolders are not part of the desktop configuration, and likewise some are not part of the embedded configurations.
The resulting compilation databases shouldn't be stitched together because you'll have duplicate entries with very different toolchains and compilation flags.

To echo what @georglauterbach also said, this isn't unique to C++ related projects, and we're also exploring some of the new possibilities with Rust and so we'd love to be able to lean on a proper *.code-workspace for that as well.

[tiborrr]

Just found this issue. Here you have another great usecase:

microsoft/vscode-black-formatter#407

[fjmacagno]

Bump, this would be really helpful.

[onlywei]

I see a lot of issues that were closed as duplicates of this one, but I don't think the original post in 2017 actually captures some of those closed issues. For instance, does this issue capture the following use case?

.git/
.vscode/
  settings.json
subfolder1/
  subsubfolderA/ <-- open VSCode here, expect settings from root of repo to load

[starball5]

@onlywei #32693 (comment)

[tomsimonart]

Another common use case are git submodules. They are always sub-directories of a project.
It would be great if there was an option to consider submodules as a "root directory" and have their own configuration.

Right now the only solution is to open it in a separate window (multi-root workspace makes it too confusing because the directory exists twice in the workspace).