Skip to main content
Software Engineering

Return to Answer

added 379 characters in body
Source Link
deceze
deceze
  • 2.3k
  • 1
  • 19
  • 19

Most of your issues with Composer can be mitigated:

  • Host a copy of the dependencies yourself. You can even keep them updated automatically via a scheduled git pull. For a large project and/or a corporate environment this is a good step.
  • Use a build system or continuous integration server which creates a production ready bundle you can upload in one fell swoop. This can be as simple as a single shell script. If you're using a proper deploy system (as opposed to manual FTP uploads), this should be trivial to hook up.

These two things should alleviate most of your concerns. You didn't indicate whether you're already using a deployment system; if not this may actually be your biggest problem. In an automated deployment your build step can be as complex as necessary, if it can all be scripted it doesn't really matter.

Regarding:

I'm using many components that are not aware of Composer; if I were to use Composer I would have to use a tool like Satis to manage these.

You are aware that you can simply write an inline definition of the missing composer.json file inside your own composer.json? For most situations this allows you to retrofit Composer support without problems.

There are many changes and updates and I find it easier to simply push these commits to production rather than setting up tags for each commit so that Composer can see the difference and update to the new version

It is not necessary to create individual tags. You can use git commit numbers just as well.

Composer is helpful just for the dependency resolution alone. More and more packages are becoming more and more complex, tracking down dependencies manually can be quite a chore. Not to mention the occasional version conflict, which is hard to catch manually and usually only manifests as obscure bugs at runtime if you don't use a dependency manager.

Getting a proper development, dependency management, build, test, deploy workflow set up is one of those things that may take a while upfront, but saves you countless hours in the long run on sufficiently complex projects.

Most of your issues with Composer can be mitigated:

  • Host a copy of the dependencies yourself. You can even keep them updated automatically via a scheduled git pull. For a large project and/or a corporate environment this is a good step.
  • Use a build system or continuous integration server which creates a production ready bundle you can upload in one fell swoop. This can be as simple as a single shell script. If you're using a proper deploy system (as opposed to manual FTP uploads), this should be trivial to hook up.

These two things should alleviate most of your concerns. You didn't indicate whether you're already using a deployment system; if not this may actually be your biggest problem. In an automated deployment your build step can be as complex as necessary, if it can all be scripted it doesn't really matter.

Composer is helpful just for the dependency resolution alone. More and more packages are becoming more and more complex, tracking down dependencies manually can be quite a chore. Not to mention the occasional version conflict, which is hard to catch manually and usually only manifests as obscure bugs at runtime if you don't use a dependency manager.

Getting a proper development, dependency management, build, test, deploy workflow set up is one of those things that may take a while upfront, but saves you countless hours in the long run on sufficiently complex projects.

Most of your issues with Composer can be mitigated:

  • Host a copy of the dependencies yourself. You can even keep them updated automatically via a scheduled git pull. For a large project and/or a corporate environment this is a good step.
  • Use a build system or continuous integration server which creates a production ready bundle you can upload in one fell swoop. This can be as simple as a single shell script. If you're using a proper deploy system (as opposed to manual FTP uploads), this should be trivial to hook up.

These two things should alleviate most of your concerns. You didn't indicate whether you're already using a deployment system; if not this may actually be your biggest problem. In an automated deployment your build step can be as complex as necessary, if it can all be scripted it doesn't really matter.

Regarding:

I'm using many components that are not aware of Composer; if I were to use Composer I would have to use a tool like Satis to manage these.

You are aware that you can simply write an inline definition of the missing composer.json file inside your own composer.json? For most situations this allows you to retrofit Composer support without problems.

There are many changes and updates and I find it easier to simply push these commits to production rather than setting up tags for each commit so that Composer can see the difference and update to the new version

It is not necessary to create individual tags. You can use git commit numbers just as well.

Composer is helpful just for the dependency resolution alone. More and more packages are becoming more and more complex, tracking down dependencies manually can be quite a chore. Not to mention the occasional version conflict, which is hard to catch manually and usually only manifests as obscure bugs at runtime if you don't use a dependency manager.

Getting a proper development, dependency management, build, test, deploy workflow set up is one of those things that may take a while upfront, but saves you countless hours in the long run on sufficiently complex projects.

Source Link
deceze
deceze
  • 2.3k
  • 1
  • 19
  • 19

Most of your issues with Composer can be mitigated:

  • Host a copy of the dependencies yourself. You can even keep them updated automatically via a scheduled git pull. For a large project and/or a corporate environment this is a good step.
  • Use a build system or continuous integration server which creates a production ready bundle you can upload in one fell swoop. This can be as simple as a single shell script. If you're using a proper deploy system (as opposed to manual FTP uploads), this should be trivial to hook up.

These two things should alleviate most of your concerns. You didn't indicate whether you're already using a deployment system; if not this may actually be your biggest problem. In an automated deployment your build step can be as complex as necessary, if it can all be scripted it doesn't really matter.

Composer is helpful just for the dependency resolution alone. More and more packages are becoming more and more complex, tracking down dependencies manually can be quite a chore. Not to mention the occasional version conflict, which is hard to catch manually and usually only manifests as obscure bugs at runtime if you don't use a dependency manager.

Getting a proper development, dependency management, build, test, deploy workflow set up is one of those things that may take a while upfront, but saves you countless hours in the long run on sufficiently complex projects.