In this post, we will discuss how a composer discovers its packages and publish it on its own. Readers will also come to know here about the security consideration that they should follow when using composer on their own application.
What is Packagist?
Composer’s package repository is referred to Packagist. This is the place where the users can publish their packages. They can also view here other person’s packages. For its default setting, the composer uses Packagist for finding packages. However, the user can also customize its settings. One of the common reasons that user may like is the customization of the setting for using the private packages.
How to Distribute Package by Using Packagist:
So you were working with your package and now you want to publish it so that others can also check your creation. If you want to post your package, you have to visit the web page: https://packagist.org/packages/submit and submit your code, it can be Gitlab, GitHub, Bitbucket or anything else. Publishing package is an easy job. The user has to make a tag by using git so they can proceed further. It is important to not set the version area in the composer.json file.
Licensing the Package:
Package licensing is an optional field. But it is always suggested to set up this field, so users can come to know how they can use the package. Every user makes a common mistake by typing a license name that is readable. But it will be better if they use “license identifier”. For example, if the code uses proprietary license, then you can use “proprietary” as a license identifier. Few of the common licenses are BSD-2-Clause, GPL-2.0., MIT, Apache-2.0, BSD-3-Clause, and GPL-3.0.
The composer has the ability to reveal all the license codes of your dependencies. To serve this purpose, just run composer licenses command. And the output will come something like this:
Different Development Versions:
Many developers face the problem when they want to check whether the new feature for their package working correctly or not. But they cannot load changes in absence of tagging a release because they are not ready to release. In this situation, they can make two different approaches:
- Adding branch alias on their package composer.json
- Taking the reference to the branch name in the application composer.json
It means that you can associate automatically with a package version. Let us suppose you are working on a 2.0.0 release on the main branch and you want to install it before releasing the tag. A nice way to make this by aliasing the main branch with a version “2.0.x-dev”
A developer form a web designing & development company can also access the 2.0 version by using the “2.0.*@dev”, or anything similar to that. Actually, composer is smart enough to find out the branch name and understand which version the branch is associated with. So, if you name a branch 2.0, then the composer will automatically treat it as the updated “2.0.x-dev” version.
Direct Reference of Branch Names:
As I already mention it earlier in this post, a developer can also use the branch name directly as a version name. This is really useful, especially when you are working on a new set of features. In order to install a branch like “new-feature”, developers need “dev-new-feature” version constraint.
Composer place a “composer.lock” file in the repo. This file secures the dependencies at a familiar state. It mainly protects the dependencies from making any accidental changes or launching bugs. The developer can also take a step further and check if the resolved set of dependencies still has any familiar security issues. SensioLabs offer special services that allow a developer to check if the composer.lock file has any security vulnerability issues. Last but not the list, the user can also use a proxy packagist.org or private central location packages.
Staying on the Top of a New Version:
If you use the latest version, you will get the updated features and a new set of tools. Users would not be able to access the latest features if the author does not support the old version. Fortunately, there is an easy command that you can run to know the version of your installed package. It will also show you the latest version. Let me show you an example that will help you to understand this fact better. If you run an outdated composer on dependencies that you have installed a month ago or more, you will see if there is any update available.
If you see above image carefully, you will understand that the versions are highlighted in two different colors, yellow and red. Yellow colored versions are minor updates and red colored versions are major updates. Before making any update it is important to understand the policy of any dependency.
The developer can also run the ‘composer update’ for the latest dependencies that their version permits. Users can also modify their version constraints, to access the latest version. Finally, you can also update your composer by using “composer self-update”.
After knowing that your dependencies are updated, you can now move your application with confidence. You also came to know here the security vulnerabilities and how to fix it.