If you want to develop your package, you should have a question for it, how to make development blazing here is my strategy for package development.
Inside your application
If your package just depends on your application, you could consider this one, the reason is, you can write tests depends on your application, for pros following:
- you don’t worry any mock the others flow in your application, it’s a coupling.
- you can choose tests where you want to put inside package or application(inside or outside) depends or not.
Here is a composer’s example:
1{2 "repositories": [3 {4 "type": "path",5 "url": "./packages/yish/my-component"6 }7 ],8 "require": {9 "yish/my-component": "dev-master"10 }11}
Outside your application
On the other hand, you may want to do an application componentable, it’s meaning “all of the components are independent”, so how does it work?
Here is a composer’s example:
1{2 "repositories": [3 {4 "type": "path",5 "url": "../Sites/yish/my-component1"6 },7 {8 "type": "path",9 "url": "../Sites/yish/my-component2"10 }11 ],12 "require": {13 "yish/my-component1": "dev-master",14 "yish/my-component2": "dev-master"15 }16}
There are several pros following:
- You don’t depend on your application, blazing development.
- Unit test scopes are limit conditions.
What’s the best strategy?
It’s not the best for all the situations, it depends on yours. If you just couple for your application, you can choose plan 1, otherwise plan 2, meanwhile, you can change it anytime when you do componentable
.
My experience is, if you are developing an application at the beginning, you can choose plan 1, it speeds up development, in the development end, you can do plan 2 for common use and stability testing.
What else?
Also, Generally, you may fork a package and do some customize or hotfix, you can add dev-
prefix to tell the composer to retrieve your package to fix.
1{2 "repositories": [3 {4 "type": "vcs",5 "url": "https://github.com/igorw/monolog"6 }7 ],8 "require": {9 "monolog/monolog": "dev-bugfix"10 }11}