Why should I (not) put my extension into app/code?

Question

a dumb question.

From: https://devdocs.magento.com/guides/v2.4/extension-dev-guide/build/module-file-structure.html

Magento installs third-party components in the <Magento install directory>/vendor directory. But we recommend adding your components to the <Magento install directory>/app/code directory. If you add your component to the <Magento install directory>/vendor directory, Git will ignore it because Magento adds the vendor directory to the <Magento install directory>/.gitignore file.

Why is it recommended to put code into app/code instead of creating a git repo and add it via composer.json?

All my code lives in repos. I do my changes there and just adjust composer.josn/composer.lock for my magento project.

I only see downsides using app/code directly. It's not update-safe as composer requirements are ignored. It makes my the repo bigger. I have an "unclean" commit log (even with squashed commits that only belong to extensions).

• What are the PROs and CONs of using app/code?
• What are the PROs and CONs of using composer?

Answer 1

IMHO, the way I see it is this:

app/code

wild-guess PROs:

• possibly a leaner/ easier learning curve for juniors. But wouldn't recommend this, even if the person learning Magento is a beginner, they should go from day 1 with learning what composer is, play with it, then go and write Magento code.
• possibly easier to find your code in the project - again for juniors who might be overwhelmed with seeing so many modules and vendors.
• possibly a more familiar approach for people coming from M1 development, where they were accustomed to writing code in app/code.

CONs:

• breaks the update strategy
• ignores version or libs dependencies
• hard to maintain if every custom module resides in a different repo and different versions are needed
• I saw projects where the whole Magento install was versioned :O :O just because the developers added the code to app/code.
• brings inconsistencies in the project.
• I saw also many times projects where 3rd party modules were added here manually - imagine what happens here if a change is needed. If that module is not versioned, it's very difficult to tell whether the native code was altered manually.

vendor

definitely PROs:

• would go 100% with this approach in both development and production. Approach should be the same, regardless of the environment using the code - so no inconsistencies.
• dependencies are respected and this is a major plus - it's very easy to see that you have incompatibilities, missing stuff, BEFORE something breaks :)
• you can require as many custom modules as you need and still be able to update them from just running a single command.
• seamless code update on any environment, no need to write lists of commands for defining update procedures for different modules, etc
• code becomes easy to move around on any environment, just add the composer.json + composer.lock, run a composer install and VOILA, you have a brand new env 100% the same as the other one(s).
• if 'accidental' manual changes are added to the native code of a module, it's easy to remove the module and reinstall it from CLI, no need to unpack, jump through hoops and whatnot.
• ease in using different module versions on different envs/ projects
• everything is in one place :)

CONs:

• can't really come up with any TBH.