Attach VSCode with settings and extensions

webksde / ddev-vscode-devcontainer-drupal-template

Drupal DDEV based development container with attached Visual Studio Code

23 stars 3 forks source link

Attach VSCode with settings and extensions #74

Open joshsedl opened 2 years ago

joshsedl commented 2 years ago

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: https://github.com/microsoft/vscode-remote-release/issues/5944

and here: https://github.com/webksde/ddev-vscode-devcontainer-drupal9-template/issues/28

joshsedl commented 2 years ago

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: https://github.com/microsoft/vscode-remote-release/issues/5278#issuecomment-992492106

joshsedl commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

Let's talk about this inside https://github.com/webksde/ddev-vscode-devcontainer-drupal-template/issues/124

joshsedl commented 10 months ago

There is now the Devcontainer CLI, but unfortunately I don't think, that is, what we are looking for. See: https://github.com/microsoft/vscode-remote-release/issues/5278#issuecomment-1785017392.