Biont
commented
1 year ago For other projects/packages, we never do this.
This discussion comes up every now and then. Apart from occasional "side-effects" in PR (when a settings change potentially sneaks into some feature branch), this does not seem to have downsides.
The benefits are:
- xDebugconfig & path mappings work out of the box
- data sources (db connections) work out of the box
- VCS integrations of sub-projects work out-of-the-box
- probably more
For projects the benefits seem to vastly outweigh any downsides. For libraries, it is often not as useful because you usually simply "don't xdebug as hard" there. But since this is a "library-turned-project" now and this PR aims to provide a "Press button, receive working WP dev env" config, I felt it makes sense to ship the complementary IDE settings as well
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) Development environment
What is the current behavior? (You can also link to an open issue here) There is no local dev environment provided by this repository, making it a bit cumbersome to work with in isolation
What is the new behavior (if this is a feature change)? A full DDEV config is provided, containing orchestration logic for a basic WP-Stash-enabled WordPress instance
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) No
Other information: