-
-
Notifications
You must be signed in to change notification settings - Fork 4
Description
The idea
I was thinking about "exposing" the web container’s php, nvm, mysql, mysqldump, etc. to the host so VS Code and other extensions can use them without having to Install a extension like Dev Containers. I know that Dev Containers and Remote SSH are great, I use Remote SSH a lot but the idea behind DDEV Manager is to help users that are starting or to help some devs that do not use docker and simply want the editor to work the same way as if they had all the tools installed in the host.
Having said that, I’m not sure if it’s a good or bad idea or if I’m over thinking and users should just use Dev Containers
How to do it
This is what I did (really quick test).
1.- In my ddev project i created a folder inside .ddev called exposed-commands
2.- Inside this folder I created some basic bash scripts that will call ddev php, ddev mysql, ddev nvm, etc.
3.- In VS Code I configured terminal.integrated.env.osx (only the workspace settings) to add the folder .ddev/exposed-commands to PATH
That’s it. Now if you open a terminal inside VS Code and run php -v it will use the web container’s PHP. The same for any other command for example mysqldump db > db.sql
The exposed command are only available within VS Code and each workspace (ddev project) can have different configuration.
https://share.cleanshot.com/nG6jFPb1
This exposed commands can be even used in tasks https://share.cleanshot.com/r4cYSF7M
Why adding this to the extension?
Because the functionality is meant to make VS Code and DDEV work seamlessly. The extension will be able to configure everything automatically, we can have some settings to disable this functionality or be able to expose only certain commands from the web container.
There’s probably thousand’s of different extensions that allow the user to configure the path to "composer, php, pest, etc." it's impossible for this extension to configure all of them automatically but we could provide a simple option where the user can define what settings must be updated with the correct path.
For example, the extension https://marketplace.visualstudio.com/items?itemName=ikappas.composer offers the following option composer.executablePath to configure composer's path. We could have settings like this:
"ddevManager.exposeCommands.composer": ["composer.executablePath"],The last part of the key is the name of the command inside the .ddev/exposed-commands folder and the value is a list of all the settings that will be updated with the correct path. The extension will get the path of the specified command and will update the defined settings but only in that workspace, so each project can have their own config. It should also handle the path correctly depending on the OS (for windows using a traditional installation)
How is this functionality different from the commands that are already included with DDEV?
The included commands ddev php, ddev nvm, etc. are great but it's difficult to make them work with existing VS Code extensions. Take as example the extension Code Runner it's impossible to point it to the web container's PHP using ddev php and even if you manage to point it it will still not work as the extension passes the local path in the host, this path does not exist in the web container so it will fail.
The exposed commands are just a wrapper for existing commands, for example: ddev php or even ddev exec /usr/bin/mysqldump but this new commands will update the passed arguments to convert any host path to a path inside the web container
So in this screenshot https://share.cleanshot.com/WqFbvCDh you can see that the extension Code Runner passes the path to the file in the host /Users/manuel/Library/CloudStorage/Dropbox/Development/Sites/testing/wp-content/testing.php
but the exposed command script will convert it to a path in the web container and the code will be processed correctly
/var/www/html/wp-content/testing.php
Final thoughts
I'm not trying to create a new functionality for DDEV, just trying to find a way to have an easier integration with VS Code for new users. At the end the user should be able to use DDEV without having to worry about how to configure it properly with the editor.
I don't even know if I'm over complicating this (would be surprising as doing this test took me a few minutes but probably because of this I could be missing something important). Maybe the "exposed" commands should be added inside the .vscode folder instead of .ddev as they are only used by this extension and VS Code, it will require more testing but at this point it's just an idea.
Would love your opinion.