Skeleton for new GitHub based libraries
This is a skeleton for a new GitHub-based PHP library.
- change namespaces;
symfony-bundleif it's a Symfony bundle;
- add keywords;
- add any additional requirements;
- change year (and/or author) in
- update this readme:
- replace all
:vendor/:package_nameoccurences with the vendor and name of your library;
- read and replace TODOs in the readme;
- replace all
- change / add files in
srcdirectory, don't forget to modify namespace;
- change / add test cases in
testsdirectory, don't forget to modify namespace;
- after pushing initial commit, add the library in Packagist, Travis and Scrutinizer.
With each relase:
- you can fix code style with
- you can run tests and code-style checks with
- don't forget to update
To start a library using this skeleton:
composer create-project paysera/skeleton-lib directory-name
Following readme is just the structure for your new library and is not related to the skeleton itself.
🔴 TODO: Change this part and title with description about the library.
🔴 TODO: Explain when and why developers should use this library – it's main purpose and/or differences from other solutions.
You can also rename this to
## Features or other purpose-like header.
Remove this part if purpose is already clear from the main description.
composer require :vendor/:package_name
🔴 TODO: explain bundle configuration or remove this part for non-bundle libraries.
paysera_something: field: value
🔴 TODO: Explain how to use this library. Use code samples for better understanding.
This library follows semantic versioning.
See Symfony BC rules for basic information about what can be changed and what not in the API.
🔴 TODO: Remove following part of this section or use instead of previous one. Remove irrelevant items, like twig functions, if they are not provided by your library.
This bundle follows semantic versioning.
Public API of this bundle (in other words, you should only use these features if you want to easily update to new versions):
- only services that are not marked as
- only classes, interfaces and class methods that are marked with
- twig functions and tags
- console commands
- supported DIC tags
For example, if only class method is marked with
@api, you should not extend that class, as constructor
could change in any release.
See Symfony BC rules for basic information
about what can be changed and what not in the API. Keep in mind, that in this bundle everything is
@internal by default.
composer update composer test
Feel free to create issues and give pull requests.
You can fix any code style issues using this command: