Run `composer`, `node`, `npm` inside wrapper scripts

[stasadev]

Issue

• PhpStorm runs composer update when you open composer.json file and when it's done with ddev xdebug on, it triggers a breakpoint on Composer itself. See https://github.com/ddev/ddev-intellij-plugin/issues/414#issuecomment-2904290192
• PhpStorm runs composer update on inactive project when you open composer.json if you already have another DDEV project running, which results in broken ddev describe -j, because only web container is started. See https://github.com/ddev/ddev-intellij-plugin/issues/263#issuecomment-1842909596
• PhpStorm cannot run npm install properly, which results in a broken DDEV project. See https://github.com/ddev/ddev/pull/7148#issuecomment-2772536983

Idea

This is an extended implementation of the idea proposed by @AkibaAT in https://github.com/ddev/ddev-intellij-plugin/issues/414#issuecomment-2851026254

• Using wrappers ensures DDEV isn't broken by PhpStorm actions
• Adding ddev exec true prevents PhpStorm from starting inactive projects

1. Create these scripts: (Note that I don't know if this can work on Traditional Windows, where you can't run chmod +x)

   mkdir -p .ddev/phpstorm-helpers
   printf '#!/usr/bin/env bash\n#ddev-generated\nddev exec true && ddev composer "$@"\n' >.ddev/phpstorm-helpers/composer
   printf '#!/usr/bin/env bash\n#ddev-generated\nddev exec true && ddev exec node "$@"\n' >.ddev/phpstorm-helpers/node
   printf '#!/usr/bin/env bash\n#ddev-generated\nddev exec true && ddev npm "$@"\n' >.ddev/phpstorm-helpers/npm
   chmod +x .ddev/phpstorm-helpers/{composer,node,npm}
   printf '*\n' >.ddev/phpstorm-helpers/.gitignore
   

   
2. Configure Composer
3. Configure Node.js (Unfortunately, coding assistance doesn't work just like it doesn't work with remote setup.)
4. Run composer install / composer update
5. Run npm install / npm update

I suggest that DDEV Integration can automatically add these scripts and configure the IDE accordingly.

[AkibaAT]

That should work as suggested for Linux and MacOS, but for Windows, we'd need bat files as well. For example, composer.bat:

@echo off
ddev exec true && ddev composer %*

Additionally, we can't use relative paths in PhpStorm for this, so we'd have to check for the correct path setting every start, in case that the user moved / renamed the project path since last time. And create a copy of all the scripts in every project.

Could we maybe just have them once and put them into the PATH instead? Maybe something like ddev-composer ddev-npm etc?

[stasadev]

Could we maybe just have them once and put them into the PATH instead?

Let's use the DDEV global directory to add these scripts (this config option is added in v1.23.2):

ddev version -j | jq -r '.raw."global-ddev-dir"'

Somewhere in ~/.ddev/commands/host/phpstorm-helpers/ is fine. We already have custom scripts in shells/, so adding another directory alongside makes sense.

But I don't understand how it'll work with PATH:

• Will PATH be altered with an extra entry for the IDE only? (I like it)
• Or are the scripts being added to an existing PATH location? (I don't like it, because I don't want to have them in my PATH when I press ddev<TAB>)

[stasadev]

Alternatively, we can store these scripts in the main ddev/ddev repo to avoid reinventing #ddev-generated assets logic here. This plugin can check if the files exist and use them.

[AkibaAT]

I got a custom DDEV executor to work for composer. I don't know yet if there's an interface I can use for NPM as well. If there is, then this would be the cleanest solution:

[AkibaAT]

There are options for node.js as well, but they're not nearly as straight-forward to use and implement as the composer one. But still, looking like there is a path forward there as well. Once implemented, we can skip the whole messy docker compose integration, as well as any workarounds via scripts.

[deviantintegral]

I suggest that DDEV Integration can automatically add these scripts and configure the IDE accordingly.

Do the scripts have to live in individual project directories? Or could they be shipped in the IDEA plugin itself?

One possible advantage of that is that if the scripts need to be different for different IDEA versions, then the plugin compatibility restrictions will allow for updates to be shipped as needed.

A DDEV executor certainly is the cleanest from a UI standpoint and is friendly to junior developers.

[AkibaAT]

I got a custom DDEV executor to work for composer. I don't know yet if there's an interface I can use for NPM as well. If there is, then this would be the cleanest solution:

This has now gone live with the 1.2.7 update, but currently requires manual activation in that version, because it's still too untested to become the automatic default.

[stasadev]

This has now gone live with the 1.2.7 update, but currently requires manual activation in that version, because it's still too untested to become the automatic default.

Awesome! It works fine for me with a running DDEV project.

When the project is stopped, and I click "Install" inside the composer.json, a popup window appears, click "OK", and nothing happens (expected behavior?):

[AkibaAT]

When the project is stopped, and I click "Install" inside the composer.json, a popup window appears, click "OK", and nothing happens (expected behavior?):

Intended, but lacking feedback to inform the user why that is. I could probably update the text to say that the project isn't currently running. Or maybe add a question dialogue asking if it's okay to start it up.

My intention was to not automatically start any containers, so it checks for the current state before executing ddev composer. And because that means the run fails, Jetbrains brings up the popup to select a different method to run the command. This is the same behaviour as when you have an invalid composer config in the project.

[stasadev]

My intention was to not automatically start any containers, so it checks for the current state before executing ddev composer.

Agree, and I like it because it fixes the original "broken" behavior when a web container is started when you have another DDEV project running, resulting in a partially running project here.

I could probably update the text to say that the project isn't currently running.

Having a little more details about the use for this executor sounds like a good idea.

[AkibaAT]

Will also have to take another crack at a similar solution for NodeJS. The problem there is that the API is a lot more complicated than for composer, and I have yet to find the path of least resistance.