Skip to content

Look for and use .devcontainer.json in subdirectories #2413

@rawtaz

Description

@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!

Metadata

Metadata

Assignees

Labels

containersIssue in vscode-remote containers

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions