0

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?
1
  • 2
    I think they are specifically talking about adding code manually to /vendor. Composer is the best option for production modules, app/code is good for development. – paj Feb 16 at 7:33
6

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.
2
  • I guess there will be no better answer. Thank you for the summary. :) – sv3n Feb 16 at 18:33
  • You are most welcome! – Diana Botean Feb 16 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.