Attach VSCode with settings and extensions

[joshsedl]

It is currently not possible to use a custom settings/extensions for the attached container, current workaround uses a workspace in the project directory with custom workspace settings/extensions, but inside a workspace it is only possible to recommend these extensions not force install them. Furthermore it seems like some workspace settings get overwritten by my "normal" VSCode settings which should not happen.

Everything documented here:
microsoft/vscode-remote-release#5944

and here:
#28

[joshsedl]

An attach to Container command will be added in the future! See here for when it's released:
https://code.visualstudio.com/docs/remote/devcontainer-cli
Source:
microsoft/vscode-remote-release#5278 (comment)

[joshsedl]

As a workaround, we could run "ddev code" on drowl-init, wait until VSCode attached to the web server and then write our settings / extensions to the attached container settings.

Unfortunatly, as we use WSL2 these attached Container Settings are sitting inside the Windows Folder Structure: "C:/Username/AppData/Roaming/Code/User/globalStorage/ms-vscode-remote.remote-containers/nameConfigs-ddev-ddev-vscode-devcontainer-drupal9-template-web.json" (check via command "Remote-Containers: Open Container Configuration")

[joshsedl]

See https://code.visualstudio.com/docs/remote/attach-container#_attached-container-configuration-files for more information about the attached container configuration file.

NOTE, that we can not use da devcontainer.json, and link our web image Dockerfile as a starting point, as then VSCode will orchestrate our container and not ddev any more. Hence the web level ddev commands will not work anymore.

[JPustkuchen]

I think apart from ddev / docker / remote the correct way here is indeed to use the .vscode folder and/or .code-workspace file instead of other possible workarounds. That's also transparent!
See https://code.visualstudio.com/docs/editor/workspaces

For production copies I think this should not be used by default.

Idea: perhaps instead of having -dev and -prod with different receipts, we should have smaller flags like the "ddev xdebug on" which add or remove defined parts, like vscode configurations, dev modules etc.?

When setting up the project, these commands would then be called automatically, so they can also be split cleanly.

If you like the idea @joshsedl we should perhaps have a master plan issue for these prod / dev things and the idea could be elaborated there... I just wrote it down here, as I came up with this when thinking about vscode integration into production projects like Drupal dev modules etc... so it's not only Drupal specific.

[joshsedl]

Let's talk about this inside #124

[joshsedl]

There is now the Devcontainer CLI, but unfortunately I don't think, that is, what we are looking for. See: microsoft/vscode-remote-release#5278 (comment).

[joshsedl]

We now can install extensions through code --install-extension <extension>, see https://code.visualstudio.com/docs/editor/command-line#_working-with-extensions I don't think they will go into the devcontainer.json, but might be a "better" workaround, then waiting for the extension popup / searching for @recommended in the shop.

[joshsedl]

Ah devcontainer up might be actually it now! microsoft/vscode-remote-release#5278 (comment), this is way better then our current approach using some random hex values to attach VSCode, which currently also seems to make us run into issues, see #162.

[joshsedl]

Created a first MR draft (only code, not tested yet) here: #163

[joshsedl]

Nope, #74 (comment) did not help... oh well, back to the drawing board.

[joshsedl]

I'll keep the issue branch open for future reference.