Why should I (not) put my extension into app/code?
-
15-04-2021 - |
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
?
Solution
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.