What is the best way to create a library using a composer?

Question

We are starting a new project and we are managing dependencies with Composer. We will probably build our application on top of Laravel 4. But we will also create our own library, which we will use for all our next projects, and not just that.

So, we have this terrible doubt: what is the best way to create a library using a composer?

If we list this new library as a dependency, every time we modify it, we will have to commit the change to the repository, and then call composer update .

That seems awful!

Is there a better way to do this?

Answer 1

I think there are two ways to deal with this, which I use depending on the case:

• The library is a clean library that is self-contained, fully tested, and developed using TDD to ensure that it all works. So it can be used with the commit, update cycle that you described is just fine, I think.
• You are developing a plugin or something that needs to be integrated into something else (application / framework), and testing it is autonomously more difficult, or you are developing it very much using your application. In this case, the version of the dev-master library is required, so Composer installs it using the git clone (if it was already installed as a tag, you will need rm -rf vendor/your/library to force reinstall, not update). You can also force this to use the --prefer-source flag for marked releases. Then, when you have a clone in the supplier directory, you can very easily work right there. If you are working in a team, although you still need to complete this commit, then update it to make sure that the others get the latest version.

The third option is to simply develop the code in the src / directory of your application until it is basically stabilized, and then you can extract it as a new package and add it back as a dependency, and then go back to the first to the two that I described, because it will be much more viable.

Answer 2

If you install a dependency on the main storage branch instead of a packaged distribution file, Composer checks the working copy in the vendors folder. You can modify this working copy directly in the suppliers folder, as if it were part of the main project, but then commit it to your own repository. You really need to make sure that composer update then keep the composer.lock file in sync with the development of this library.

This is an even more convenient way to develop a project in tandem with dependency.

Answer 3

If you are aiming to create a truly awesome library, then you should try to develop it independently of any other software that you create.

He must perform only one exact task. And this is probably done after some commits, so for the initial creation of the library it takes only one week or two to arrive at a stable first version. And this version can be tagged and then used elsewhere.

When marking, strictly follow semantic version control - this way you can use a library with a version restriction, for example "~ 1.0", which means at least version 1.0, but any is acceptable up to 1.9999 if it is not 2.0 (which would mean incompatible changes).

And then you really do not need to update any other software when releasing a new version of the library. You only need to update if you want to include the corrected errors. Without corrections, you can update, but there is no need to do this immediately after the release of a new version of the library.

The composer will take care of all the dependencies you need. The most important thing if you run the new library is to include composer.json from the very beginning in the repository.

What if you really want to always include the latest version of the library in any other software that you write? I am not sure that you are aware of the consequences of this. This means that you are strictly tying your other software to the latest version of the library. Break this version or submit an unpleasant mistake, and all your software breaks. Therefore, the ability to upgrade or not is actually a function. You will find that all external libraries that you could use will follow the same release mechanism: they mark the new version if an important bug is fixed, or if a reasonable number of new functions have been implemented. They do not wait until you approve the new version - you must approve THEIR new version of your software by explicitly updating it to the latest. And the same goes for the internal library.

Try to avoid messing with the dev-master solutions mentioned here. They may work, but Composer works best when used with tags. If you have a fairly stable state for your library, mark it "0.0.0" and enable this version everywhere, not "dev-master". And then the tag according to the rules of the semantic version.