The composer suggested an approach for internal packages

Question

Some prerequisites first

Our company, a small startup with four developers, is starting to refactor our products into reusable modules to simplify the development process, increase productivity and, on the way, we would like to introduce unit tests that are suitable.

As usual with a small start-up, we cannot afford to spend too much time on development, but, as we see, this is extremely important for the success of our business in the medium and long term.

We currently have two end-user products. Both Laravel (PHP) applications are based on our own internal business layer, mainly consisting of web services, a quiet apis and a huge database.

This business layer provides most of the data for these products, but each of them makes full use of it. We plan to build other products in the near future, besides maintaining and improving those that are almost complete.

For this to happen, we intend to abstract the general logic of these (and future) products into reusable and untied modules. The obvious choice seems to be Composer, even with our little knowledge about it.

Now to the real question

I would like to ask other opinions on how to develop internal packages based on the test. Should each module be a composite package with its own unit tests and require its dependencies, or should we create a single package with each module namespace?

To clarify a bit, we would like to have, for example, the CurlWrapper module and which is required for our InternalWebserviceAPI module (and several others).

I personally like the idea of ​​having completely separate packages for each module and declaring dependencies on composer.json, which would mentally provide a decoupling and allow us to publish some of these packages as open source sources someday. It can also simplify breaking changes to these modules, because we could freeze its version on dependents that need to be updated.

Although, I also believe that this separation can complicate the complexity and may be more difficult to maintain and test, since each module must be a project at its own level, and we do not have all the capabilities to track so many small projects.

Is Composer the perfect solution to our problem? If so, what would you recommend: one package or several packages?

Change 1:

I would like to note that most of these modules will be:

• Libraries (i.e. retrieving an identifier from a youtube URL or converting dates to "x seconds ago")
• Packers (e.g. fastened curl wrapper)
• Facades (from our several web services, they require two other types)

Answer 1

Yes, composer is the way to go, and I recommend you use separate packages.

You do not know when you need these modules. It is better to create many separate packages and be able to include all (or one) of them than to create large packages, and they need more time to break the package in several cases when you need some classes from it.

For example, see the Symfony2 project. These are many components that are required for the full-screen Symfony2 framework, but you can also use some components in your own project (for example, Drupal8). In addition, as Symfony2 receives more and more packages, it seems that it’s so useful to have small packages that people put when they break large packages.

Answer 2

Alternative to using separate packages: use separate composer.json files for each subproject.

This gives you the ability to save all your libraries in one repository. When you reorganize the code, you can also split autoload and sub-library dependencies.

If you get to the point that you want to unscrew the library in your own package with the version, you can take the last step and check it in your own repository.