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 Xdebug stopping on random incoming connections from stdin and composer when using command line input #414 (comment)
• 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 Since using the plugin, I am getting a lot of orphaned networks and failed ddev starts #263 (comment)
• PhpStorm cannot run npm install properly, which results in a broken DDEV project.
  See fix: don't wait for one-off containers from PhpStorm, fixes #7146 ddev#7148 (comment)

Idea

This is an extended implementation of the idea proposed by @AkibaAT in #414 (comment)

• 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.