Ttdfjt

I prefer creating a new module repo in git, adding that via composer, and letting composer check it out to vendor so that I can develop in <magento-root>/vendor/[org]/[module] from start to finish and my local environment matches production as much as possible.

However, the Magento docs suggest starting a new module in <magento-root>/app/code/. I'm trying to understand different workflows, so are any benefits to doing it that way that I'm missing?

In my development environments I try to treat the vendor directory as read-only and the property of composer. Although you can of course, my rule is that you don't in normal circumstances edit the vendor files. The first reason is that it's at least possible for a composer update to clobber your local changes. The second reason is that it simplifies your workflow to know that the composer files are in a settled state so you don't need to look there for changes or bugs. I usually have file permissions set in a way that they're not convenient to edit.

The flow should be: develop the module in app/code/ in dev, and then get it to the next done state and submit it to composer. Getting it to production is then a matter of a composer require/update on the production server. That way you know that production doesn't have any surprise new changes since the last incremental release.

There are no differences from Magento's perspective between having the code in app/code or in /vendor. It works the same. Not sure why it's a benefit to you to have the file systems in dev and production match.

I'll post my thoughts on the benefits of developing under vendor via a git repo in composer.json instead of app/code ...

Primarily, I don't have to think about where my code resides in dev vs. integration vs. production. It's always in the same place, organized/managed by composer. This simplifies many common developer tasks. For example,

1. Searching - If I'm searching on a string across the code base, I can just grep/ack in ./vendor. I don't have to search in app/code and vendor, or from a common root dir and search perhaps many unwanted dir. Similarly, for find, whether I'm looking for all cron_tab.xml files or all js files, I just have to look in vendor.




2. Debugging - I don't have to map different paths in my IDE for debugging in dev vs. integration vs. production. Once again it's always in vendor using a consistent path - not certain paths are in one dir and others are in a different dir depending upon the stage.




3. Patch files - If I'm deploying to Magento cloud and applying a patch/hotfix, my generated paths will always be correct. I won't have to create a patch file, and then update the paths.




4. Composer scripts (pre|post-autoload-dump, post-install-cmd, etc.) - since I keep those scripts in a composer module, when referencing them in composer.json, I don't have to update their paths for the different stages.




5. Shell cmds, cli snippets, etc. in a terminal - if the paths are the same, I can run them in the same way with a simple cut and paste in every stage.




6. Finding differences between dev vs. integration vs. productions becomes as simple as scp/rsync and diff -r (or any other gui diff tool)

What hasn't been a problem for me - composer clobbering my files. I'm not often running composer update while I'm actively developing a module. However, I am frequently committing my code, so it's in git if something should happen. Also, composer will always alert you to changes that could be clobbered, and you have to assert affirmatively that you want composer to overwrite those changes. Lastly, any code that I'm actively working on is also usually open in my IDE, too. If it detects a change, it'll ask me if I want to load the new or old. I'm not sure that I've ever lost code to composer clobbering, but yes, it could happen.