Hands-on development of your first composer package

Composer is a dependency management tool for PHP, this article explains how to build a package and submit it to packagist so that others can easily use your package through composer.

There are several steps to developing the composer package:

1. Initializing the Composer.json file

2. Defining Namespaces and package names

3. Implementing the functionality that the package needs to implement

4. Submit to GitHub

5. Registering packages in Packagist

Initializing the Composer.json file

After you install composer, you can run composer init locally by setting up Composer.json with an interactive command line.

Several of these properties are described below, along with general settings:

1. Name This property defines the package name, to/from, preceded by the vendor name, followed by the package name, and the vendor represents the unique name provided by the developer for the Packagist website, which is used to organize the package and to prevent naming conflicts. Therefore, it is best to first visit Https://packagist.org/packages/yourvendorname the URL to replace the yourvendorname with the name you want to take, if the page does not have 404, the description has been registered.

2. License License. About the license, we suggest two articles, open source project license Introduction, how to choose License

3. Require the dependencies required to install the current package. The current package will be installed only if all dependencies are installed.

4. AutoLoad This configuration is primarily PSR-4 or PSR-0 settings, it is recommended to use the PSR-4 standard.

http://json-schema.org/introduces the definition of JSON schema and the implementation of each language to its various functions, with validator implementation, in which the JSON schema validator is an online authentication service. In fact, the simplest is to use composer validate Composer.json to verify that the file is faulty.

This is the video of the setup Composer.json I demonstrated

Project structure

With the single sign-on SDK I developed for example, this project is based on Laravel, which realizes the simple access of the site access single sign-on system, and the application simply registers with the server and implements the specified interface to access SSO.

The project structure is a typical MVC structure,

. └──geo    └──geosso        ├──license        ├──readme.md        ├──composer.json        └──src            ├──contracts            ├── Http            │   ├──controllers            │   ├──middleware            │   └──requests            ├──paramsbean            ├── Providers            ├──support            └──config12 Directories

LICENSE, README.MD and Composer.json are added manually after the tree-d is run.

The project root is defined under SRC and is also defined in Composer.json so that when composer loads the package, it knows how to parse the file path through the namespace.

The Http directory represents the request response, the Controllers represents a legitimate request for the Controller, middleware represents the first level of the request, through the middleware to intercept the request, requests to obtain the front-end request and filter the request.

Contracts represents the interface definition. Paramsbean represents the parameter encapsulation of the application layer when communicating with the underlying service, and the parameters passed through the Bean, rather than passing the array to make the call consistent, and forcing the interface invocation to do type detection, which can be used to a large extent to unify the parameter passing between the layers.

Providers represents the service container of Laravel, through the service container, can register routing and configuration, load helper class, BIND interface and its implementation.

Support is the helper class, the encapsulation of commonly used logic-independent functions, the Config represents the application of its own configuration, and the configuration can be easily set by config and called using the Global function config ().

Submit to GitHub

Following the previous steps, a package has a basic skeleton, which is then uploaded to GitHub, configuring the project, integrating the continuous integration service, and releasing the Open source project license.

GitHub initializes the project with the option to generate a. gitignore file, select the license, initialize the readme.md file, switch to the local project directory, and then upload the directory to GitHub as follows:

>git Init # initializing warehouse >git Remote Set-url Origin--push--add Git@github.com:jayxhj/geosso.git # Add remote tracking Warehouse address > Git Add. > Git commit> git push origin master

Submit to Packagist

Packagist gets the address of the package metadata information for composer by default, obtains the metadata information from Packagist, and then pulls the code from GITHUB. So, when uploading your development package to GitHub, you need to register it in packagist so that people around the world can pull your code through composer.

It only takes three steps to submit to Packagist:

1. Register your account

2. Submitting a development package at Https://packagist.org/packages/submit

3. Set Webhook to synchronize to packagist in a timely manner after submitting a package update

Since then, a basic package development has ended. By composer to manage PHP dependencies, by writing the composer package to expand your class library, by introducing other libraries to populate your functions, you don't have to reinvent the wheel.

