Look for and use .devcontainer.json in subdirectories

[rawtaz]

It'd be great if VS Code didn't search for .devcontainer/devcontainer.json and .devcontainer.json files in the root workspace folder only, but also in some configurable depth of subfolders (or the entire tree, see below).

Imagine for example the following (simplified pseudo) structure for a web project:

root/
+-- backup/
|      +-- some_db_backup_2002-02-19.sql
|      +-- some_db_backup_2002-02-23.sql
+-- notes.txt    # File with various notes and snippets used by the developer as part of working on the project.
+-- references/
|      +-- Some technical reference 1.pdf
|      +-- Some technical reference 2.pdf
|      +-- <more files with material used by the developer>
+-- graphics/
|      +-- Original logo.svg
|      +-- Adjusted logo.svg
|      +-- <more files with graphics edited by the developer before placing the final work in the actual source code of the project>
+-- source/
|      +-- .git    # Git repository for the project.
|      +-- .gitattributes
|      +-- .gitignore
|      +-- controllers/
|             +-- <various files>
|      +-- models/
|             +-- <various files>
|      +-- wwwrroot/
|             +-- adjusted_logo.svg
|             +-- some_style.css
|             +-- <various files>

As you can see the actual source code of the project, the files and folders making up what will finally be put into production, is all under the source/ folder. Many VS Code users would use that folder as their workspace root.

However, when you have a project that does contain a lot of material besides the code, material that it doesn't make sense to version control, a workflow is to keep that material in sibling folders to the source/ folder, as shown above, and open the parent folder of that as the workspace in VS Code. That way one has access to all the material, reference files, backups, etc available in one's workspace in VS Code, alongside the source code.

I haven't found a way to make VS Code look further/deeper than the root folder of the workspace for the devcontainer files though. This means that if you like in the example above have your VCS repository in the source/ folder (since the files above/sibling to that aren't relevant for version control - it's the source/ folder that's the main actor in the project), and you want to version control the devcontainer files, putting them in the source/ folder won't work, because VS Code won't detect and make use of them when you open the root folder in the example above in VS Code (as opposed to the source/ folder).

I wish that we would have two options to configure this in VS Code:

• One option to tell VS Code to look for .devcontainer/devcontainer.json and .devcontainer.json files N levels deep into subfolders to the workspace root folder. E.g. remote.containers.configSearchDepth = 2 would make VS Code search for devcontainer files in both the source/ folder in the example above, as well as one level of subfolders to that folder (useful when you have a more complex project root folder, e.g. with several different source/ folders containing different code).

• One option to provide an exact path relative to the root workspace folder, for where VS Code should look for .devcontainer/devcontainer.json and .devcontainer.json files. E.g. remote.containers.configSearchPath = 'source/' would tell VS Code to look for devcontainer files in a subfolder named source/ to the workspace root folder.

An alternative to this would be to simply make VS Code pick up these files anywhere in the files tree. I'm guessing that VS Code already has a list of all files and that the extension wouldn't have to do a full scan to find such files, instead it can just ask VS Code about it? This guess is based on the Cmd+P showing a really responsive file listing in VS Code, so it appears VS Code already has a list of files in mind.

Let me know if anything in the explanation or use cases is unclear. Thanks!

[bamurtaugh]

Thanks for opening this issue! I believe this ties back to https://github.com/microsoft/vscode-remote-release/issues/1460. Although 1460 focuses on the multi-container scenario, it seems like the main ask is still to have VS Code look beyond the root level for a dev container definition.

If I'm understanding your ask and its relationship to the other issue correctly, I'll go ahead and close this thread so that we can focus our discussion there.

[rawtaz]

@bamurtaugh This issue and #1460 are related, but not the same thing:

• #1460 is not about making VS Code search for .devcontainer/devcontainer.json and .devcontainer.json files both in the root and subfolders (N levels down or with specified paths to them). It's more about making VS Code handle multiple containers in a multi-root workspace. Those are two different things.

• This issue (#2413) is specifically about the former - VS Code being able to search for .devcontainer/devcontainer.json and .devcontainer.json files N levels deep, all levels deep, or in specific paths - all depending on configuration.

• Solving the feature request in #1460 does not automatically solve the feature request in this issue (#2413).

For these reasons, while I understand and agree with your thinking in terms of housekeeping, I would suggest that we keep this issue open, as it's separate from #1460. Implementing either of them won't solve the other one, hence they are separate and cannot be tracked in one and the same issue (by merging one of them into the other).

[PavelSosin-320]

You can call it "Unixoid conspiracy" but the location of the configuration files and how all utilities search them, including configuration hierarchy is derived from the Linux Filesystem structure and the purpose of every folder is fixed in the corresponding specification for the Linux filesystem. It makes Linux developers' life simple. It doesn't restrict the developer because folders can be easily chained using symbolic links. It's hard to implement in Windows without the creation of a kind of directory list where configuration files are searched, exactly as Windows uses Path environment variables.

[rawtaz]

@PavelSosin-320 This issue has nothing to do with whatever you wrote, please don't write off-topic comments.

[bamurtaugh]

@rawtaz I appreciate your response here. I had a similar thought/hesitancy, and based on your comment as well, I'll keep this issue open as a separate feature request.

[rawtaz]

Thank you! :)

[PavelSosin-320]

@bamurtaugh It does VSCode maybe the only IDE which allows the creation of empty workspaces and projects from scratch. Other IDEs have features "Create workspace" and "Create a new project for..." and immediately populates the project file structure with all necessary dotfiles templates. Even an "empty" project can be built with the default build configuration successfully. At any point of time project can be committed to the repository and another developer can fetch and rebase it with own local code to use as a base code line to continue development from the same point where his/her college committed it. This is the way of team development. dotfiles can't be moved over project structure because after the git rebase by the second developer his/her local build will be broken and no manual git rebase will help.

It works in such a way in my former company and ensure amazing productivity.

[rawtaz]

@PavelSosin-320 You are not making sense, and what you write seems to have absolutely zero connection with what this issue is about. Please do not comment any further in this issue, as you are just spamming the thread with irrelevant comments. Thanks.

Can some moderator please Hide these off-topic comments by me and @PavelSosin-320?

[pac-rirl]

Is there any update on this issue?

I would like to simply be able to have VsCode open a SINGLE devcontainer.json and etc; just from some other place than .devcontainers in the root....say

./application/.devcontainer/

with all the normal stuff in here where application is nested one or more levels beneath the root. It could be nice if the structure could be nested; if more then one is found; it should pick the first one....

./application/directory1/directory2/.devcontainer

[qobilidop]

https://code.visualstudio.com/remote/advancedcontainers/configure-separate-containers seems to work for me.

[chrmarti]

Indeed, this has become available as a stable release in Dev Containers 0.275.0. Closing this issue, thanks.