@dunglas do you know if I can in the php container point the php to /workspace/api/ (or /srv/api/) instead of /srv/app/ so I will not need to have both?
because now PHPUnit run from /workspace but Caddy run from /srv and so I need one regular .vscode/launch.json for PHPUnit and one with a "pathMappings": {"/srv/app": "${workspaceFolder}/api"} for Caddy and switch between them depending on what I'm debugging

@dunglas do you know if I can in the php container point the php to /workspace/api/ (or /srv/api/) instead of /srv/app/ so I will not need to have both? because now PHPUnit run from /workspace but Caddy run from /srv and so I need one regular .vscode/launch.json for PHPUnit and one with a "pathMappings": {"/srv/app": "${workspaceFolder}/api"} for Caddy and switch between them depending on what I'm debugging

So in 3.1.x path was "/srv/app/", in 3.2.x it was changed to "/app/" and simplified. In the last commit I changed it to "/srv/api/".
Normally you will just have "/srv/api/". In devcontainer mode, you will have "/srv/" with the full project in it in one place (including the "api" subfolder).

As I mentioned in the symfony-docker project, i not in favor of this addition.
However, this can be done in a recipe to configure these files on a project.

@maxhelias can you elaborate on the "recipe"? I'm not familiar with this terminology

@ili101 you can see more information here : https://symfony.com/doc/current/quick_tour/flex_recipes.html#flex-recipes-and-aliases

@maxhelias in response to your feedback here and on dunglas/symfony-docker#523

A very strong opinion in customizations.

I have removed my opinions/examples in the Clean commit (I updated and moved my examples to another branch https://github.com/ili101/api-platform/tree/DevcontainerMy).
The PR now only contains the default Devcontainer template and an Xdebug setup config. I can also remove the Xdebug config and instead add to the documentation short instructions on how to configure it if you think it's more appropriate.

this can be done in a recipe to configure these files on a project

I think this is more appropriate for a template than a receipt for two reasons:
One of the advantages of working in a container is that you don't need to install and maintain anything on your PC. Personally, I don't even have PHP installed. So making it a receipt will negate this benefit as it requires PHP and composer to setup.

Another benefit as we are on GitHub is Codespaces. Basically, if you have Devcontainer setup on the repo itself you can open it in the browser. So for example you want to check a bug or present API-Platform somewhere, all you need is a browser and you have a running environment, IDE, and a debuger. If you want to check it out:

1. Open the PR branch and click "Code" -> "Create codespace"
   
2. After it finishes loading the online editor you can browse to the API-Platform instance by going to "Ports" -> "Add Ports" and adding 80 and 443. now click on the globe to open the website in a new tab. Optionally you can also F5 to start the debugger, add a breakpoint, and browse in the other tab to hit the breakpoint:
   
   

Updated and squished all commits.
Also as of the Debian switch Devcontainer "features" now works 🎉 My example branch,
I also tried PhpStorm Devcontainer (beta) again as the last blocker was Alpine. I passed the Alpine error but I got other errors like it's getting confused about finding the Dockerfile from the composer file and also for the "features". searching their bug reports, it looks like it was already reported multiple times in the last month.

My 2cents on this feature request.
Few context : non english fluent | maybe back behind keyboard after some years off

As I can maybe understand to rely on symfony/flex for this kind of things for dunglas/symfony-docker repository ;
I'm convinced that api-platform distribution should merge this 🙏

At least, those lines which concerned /srv/app -> /srv/api to avoid wasted time/energy.

Yes, I'm not okay to enable xdebug by default ; but I'll be really happy if it can be commented out and not totally erased.

I mean, you embrace tons-of standards and how those things going in industry. By this way, you are some light-in-the-dark for developers without active mentoring or well formed team and who keep eyes open on your stuff 💓

Please, DevContainer extension is this kind of welcome-things for quickly learn / play / discover / (work?).

@ili101: Thanks to publish your retex and avoid this 2days-trap 👍
What about comment out xdebug related things ? No need to enable by default, but really cool to find how activate this if needed.

Doux-jésus, je ne suis pas client de la hype ou des annonces marketing, m'enfin être DevContainer compliant, c'est du slogan tout fait non ?

Sans vouloir jouer sur l'éloquance, c'est un coup à finir couplé avec sa persistance ces broutilles 😅

./me little disapointed about this 'not-already' merged request, @ili101 will maybe not rebase forever his/her branch :/

Removed Xdebug config for VSCode (there are no longer any VSCode specific configs/files left).

To setup Xdebug on VSCode

1. Open the template/project folder in VSCode or Codespaces.
2. Open the file .devcontainer/compose.devcontainer.yaml and uncomment the environment variables to enable and setup Xdebug:

    environment:
      # See https://xdebug.org/docs/all_settings#mode
      XDEBUG_MODE: debug
      # Enable the step debugger
      XDEBUG_SESSION: 1
      # Override api/docker/php/conf.d/app.dev.ini
      XDEBUG_CONFIG: "client_host=localhost"

1. Open the Extensions tab (Ctrl+Shift+X) and search for PHP Debug, right-click the result or click the gear icon and select Add to devcontainer.jsom so the extension will be automatically installed in Dev Container when started.
2. Start Dev Containers by opening the command bar F1 and search/select Dev Container: Rebuild and Reopen in Container (or Dev Container: Rebuild Container if you are already in Dev Container, or Codespaces: Rebuild Container).
3. Open the Debug tab (Ctrl+Shift+D) and click create a lunch.json file, and select in the opened command bar PHP.
4. Start the debugger by clicking F5 (or in the Debug tab, select Listen for Xdebug and click the play icon).
5. You can now use the debugger, set breakpoints, and execute the code to trigger it by browsing to the relevant code like https://localhost/docs or by running PHPUnit, etc.

My bad, as I said, I was far from keyboard ^^'

Devcontainer is closed source and seems Microsoft thing, I will not using this. (I'm using codium)

Anyway, it didn't change my point of view for this thing :
If mapping /app unless /.../api is a trap for some users (vscode/devcontainer users), let fix that ?

Cheers

Devcontainer is closed source and seems Microsoft thing, I will not using this. (I'm using codium)

Actually, it's an open-source standard created by Microsoft and supported by VSCode and PhpStorm and some other tools.

I assume you are referring to https://vscodium.com/. I see the VSCodium community is upset that while VSCode and the Devcontainer specification are open source the VSCode remote server implementation is not VSCodium/vscodium#1229 VSCodium/vscodium#1696. So the VSCodium team needs to make their own implementation or push Microsoft to open VSCode remote microsoft/vscode-remote-release#1925 (top 10 most 👍 issue, so maybe at some point?)