0

I thought when migrating projects to composer, one big benefit would be to have a small project repository left where alle the composer managed stuff (TYPO3 sources + public extensions) could be excluded from VCS. On deployment, a „composer install“ on live system would always lead to the desired state without risk.

But official TYPO3 documentation says:

You should not run composer on your live webspace. You should always run composer on your local or a dedicated deployment machine, so you can test if everything worked fine. After running your tests, you can deploy the vendor and public folder to your web server.

I cannot follow why. Because this leads to each projects repository needs to contain the whole TYPO3 sources in the projects VCS, although they might be excluded there. What are the reasons for this approach and what are the risks with „my“ approach?

EDIT: Of course i ment to specify exact version numbers until revision level for composer packages. Doing so, would there still be any risks with my approach?

JKB
  • 499
  • 2
  • 13
  • Please share more details - what exactly did you expect? That one single installation of Typo3 covers a lot of instances of multiple servers? That `composer update` should not be used anywhere else than on your local development server is widely documented, and this is in no way related to Typo3 – Nico Haase Mar 14 '21 at 14:17
  • "Because this leads to each projects repository needs to contain the whole TYPO3 sources in the projects VCS" - no, why do you assume that? As usual, the `vendor` folder should be ignored and not put under version control – Nico Haase Mar 14 '21 at 17:38
  • @NicoHaase But how is vendor beeing deployed in this case? Why not to restore its state by just deploying composer json/lock and run „install“? – JKB Mar 14 '21 at 18:38
  • How do you deploy your code otherwise? Usually, you should build a pacakge with your whole application and deploy that - this way, you don't need to install Composer on any other server, as there is no need to install Composer on any production system – Nico Haase Mar 14 '21 at 21:17

2 Answers2

1

composer can be used in multiple ways and I wonder, too, why the TYPO3 docs show such a strong opinion here (without reasons?).

It refers to this model:

  • Local development system with composer for changing composer.json/composer.lock

  • Build environment/CD pipeline runs composer install --no-dev and just copies the ready-built filesystem to the staging/live system

  • Live server without composer integrates with user data (database & /fileadmin)

This is preferred by some (me included) because it facilitates a testing step in a reproducible (build) environment. It also works well if the build step consists of more than composer (e.g. asset building).

While only for composer it wouldn't make a big difference if it would have to be installed on live (+ its dependencies), the more build steps you have the more "development" software you would have to put on live. And that's probably where some drew a line and decided development -> build -> live is a much more powerful model.

While the build environment could very well be on the live server, I wouldn't want it to be in a published state ( I don't know if you refered to that). So I would do at least some copying around (or rather symlink switching) in order to make sure that problems during build/testing do not affect the published site.

Other models work, too.

Jonas Eberle
  • 2,835
  • 1
  • 15
  • 25
-2

When you use the composer to fetch the sources for your TYPO3 environment by composer install , then you do not know exactly which version of which TYPO3 extension you will get. The composer.json files define a range of allowed version numbers, and not an exact version number. When you have a local or deployment environment, then the composer installation will give you a state extension 1 in version 1, extension 2 in version 2. Then you test everything. After 2 weeks you decide, that everything is ok. But if you would use composer after 2 weeks on your live system, it could happen that extension 1 is now in version 2 which has a severe error. Then a composer run would bring you this buggy version 2 of extension 1. This is not what you wanted.

A workaround exists.

How to install a specific version of package using Composer?

Franz Holzinger
  • 913
  • 10
  • 20
  • 3
    That's not entirely true. The composer.lock file defines exactly which version will be installed. – Jonas Eberle Mar 13 '21 at 22:14
  • @JonasEberle Thats what i‘ve assumed within my question. And that was the reason for asking ;) – JKB Mar 13 '21 at 23:43
  • 1
    Besides the "workaround", simply never never run `composer update` on a production system – Nico Haase Mar 14 '21 at 17:39
  • @NicoHaase But running composer „install“ on live is o.k.? – JKB Mar 14 '21 at 19:12
  • @JonasEberle: The questioner did not tell that he already used a composer.lock on the server. This information has been given after my answer. I doubt that `composer require vendor/package:version` does not entirely work. – Franz Holzinger Mar 15 '21 at 09:04