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 notifications@github.com 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 https://github.com/Microsoft/vscode/issues/28344 for more details.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/32693#issuecomment-323761494, 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 https://github.com/Microsoft/vscode/issues/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 https://github.com/Microsoft/vscode/issues/32693#issuecomment-456035663, 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 https://github.com/microsoft/vscode/issues/45399 then https://github.com/microsoft/vscode/issues/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 https://github.com/microsoft/vscode/issues/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

[danguilherme]

It would be really nice to have this... I have different settings for my personal projects and for the company projects, and I don't wanna add a .vscode folder in a repo where I'm the only one who'd be using it. Also there wouldn't be a need to add an environment-specific entry to .gitignore if this feature was implemented.

I'd expect something like this to work:

git_workspace/
├── .vscode
│   └── settings.json # global settings, my preferred ones
├── my-personal-projects/
│   └── project1/
│       └── .git/
└── company-projects/
    ├── .vscode
    │   └── settings.json # local settings, overrides some of my personal ones
    ├── project2/
    │   └── .git/
    └── project3/
        └── .git/

[m1stermanager]

this would be awesome. are there any updates?

[shiftycow]

Another use case for this is submodules: I have a project composed of several submodules, one which has different linter rules. It would be nice to be able to have my editor pick up on the submodule's .vscode/settings.json file and, say, set the indentation level for files in that directory.

[bbugh]

This is also important for Yarn 2/3 PNP setups, which have to specify which sdks are available. For example, two of our sub projects require different versions of TypeScript (don't ask) and have their own .yarn/sdks folder, but we have to open the project folder separately in order for VSCode to correctly choose the right TypeScript version for each project.

[chriswoodie]

This is crucial for configuring different auto import methods. We need project-relative in our libs and non-relative in our consuming applications.

[robharman]

Jumping in on this as it seems to be the only way to set language associations by filetype. I've got a lot of IaC projects which have YAML files with different syntaxes I'd love to be able to set "files.associations" with per-subfolder, rather than just by root project.

[adonig]

It would help with AWS SAM projects where you can have a folder tree structure like this:

 sam-app/
   ├── lambda1/
   │   ├── __init__.py
   │   ├── app.py
   │   └── requirements.txt
   ├── lambda2/
   │   ├── __init__.py
   │   ├── app.py
   │   └── requirements.txt
   ├── template.yaml 

Those two Lambda functions might run with different Python runtimes. You might even add a third Lambda function that runs with Node.js instead of Python.

[Falven]

It's been 5 years and this is crucial for monorepos...

[teleksterling]

I was amazed to find that it wasn't already a longstanding feature. I just assumed that nesting/inheriting settings would be a thing because of course it would.

I'm even more surprised that it's been an open suggestion for 4.5+ years and not yet implemented.

It must be more complicated that it seems at the conceptual level!

[thetrompf]

There are a lot of things to consider e.g. in typescript if each root in the workspace use a different version of TS, should there be spinned up a language server per root, or is it up to each language server to support multiple versions of the compiler? Which part of the "editor platform" should have which parts of the responsibilities.

[teleksterling]

My workaround (for my use case of formatting all files in a specific subfolder as JSON) was to add a file filter that included the path to Files: Associations:

"/subfolder/": "json" I could see this being easily extended for others, if they're only after similar outcomes.

[thetrompf]

While that is a great workaround for very simple extensions that are just "running a command against the codebase" I don't see it work with a common, but a quite more complex set of extensions such as language servers at different versions of the language.

Actually if we just consider the JSON formatter, what should happen if the roots define their own formatting rule settings for the json formatter extenstion. Where should the implementation burden live, in the vscode platform or at the extension authors.

Personally I think it would work best if the extenstion authors should handle this, so they could decide what it would mean to run in a multi root environment, but I don't see a lot of adoption in that case, but I don't see an one-size-fits-all solution that'll work great if the vscode should handle all of it.

The difficult thing here is to "guess" what extension API that'll resolve as much the platform can offer to the authors to get them as long of the way as possible and the needed "hooks" for the extensions authors to fill in the blanks to give the users a good experience.

[pdrgds]

@sandy081 I'm interested in solving this, can I get directions?

[sandy081]

I am afraid that this can be contributed through a PR given that it is a big plan item. But we would appreciate to collect ideas which can help in designing the solution. Thank you.

[AtomBaf]

Hi all Also using a monorepo with a lot of projects, in several languages, with several, unaligned directory hierarchies.

Using a multi-root workspace I can manually add each 'project' folder individually and have a seamless development experience (mainly python+jupyter). So, if there was a setting in the a my.code-workspace file which would allow the system to auto-discover project roots, that would be a very good start.

Eg instead of having something like:

{
    "folders": [
        {
            "path": "/git/monorepo_project/folderA"
        },
        {
            "path": "/git/monorepo_project/folderB"
        }
    ]
}

{
    "foldersRootPath": "/git/monorepo_project"
}

A basic way for the auto-discovery to work is by browsing all sub folders and check the presence of an .vscode/settings.json It could also be a more featured glob pattern for instance.

[DibyodyutiMondal]

I too would love to see this feature implemented. My use case is for javascript/typescript.

As a simple example, I have an angular project web-client, a server-side project app-engine; both of which depend on project models, which follow the folder structure:

- apps
  - web-client
  - app-engine
- libs
  - models
- ... other stuff

app-engine and models target ESM, not commonjs.

Now, ESM requires the imports end with the file extension. So to run the server, it must use the file extension, and the same goes for models because it is going to be used by app-engine. However, web-client is built by the angular cli, and I am not sure if it's the cli or webpack, but the build process fails if I use file extensions inside web-client. Since models is a package (i.e. it has a package.json file with "type": "module"), angular does not complain about file extensions inside models.

Thus, I need the following vscode settings inside app-engine and models, but not in web-client

  "javascript.preferences.importModuleSpecifierEnding": "js",
  "typescript.preferences.importModuleSpecifierEnding": "js"

Having folder-level settings.json work the same way package.json or tsconfig.json works, would be wonderful.

Workaround: Currently, I am having to exclude the individual project folders in the root .vscode/settings.json, and adding them as workspace folders in the .code-workspace file, then adding the folder-level .vscode/settings.json in order to get what I need.

[superherointj]

I miss this.

I also miss extensions being local to projects, specially in a monorepo, extensions should be turned on according to projects and not having all of them enabled by simultaneously.

[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:

• 15909

• 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 #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:

https://github.com/microsoft/vscode-black-formatter/issues/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 https://github.com/microsoft/vscode/issues/32693#issuecomment-1556012889

[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).