适当的Composer Package + Git开发工作流程

Question

I'm trying to figure out proper development workflow when developing my own Composer package. I understand how to create a composer.json and get the package on Packagist. That's not the problem.

Let's say I have a simple PHP Class that I added to Packagist. When I'm ready to make changes (bug fixes, new features, etc) to it, what do I do?

Do I simply composer install the existing package to a local development environment and make my changes to my package directly in the vendors directory? If so, that directory is not a cloned git repo, so how do I commit and push my changes?

Or, do I clone to repo to a random local directory, and then composer install to a development environment using VCS and a custom local repository that points to my cloned git repo? And if so, I assume I make my changes in the repository and not in the local vendors directory. Then how do I get my development environment to stay updated? Do I seriously have to do a composer update every time I hit save in a file in my package?

Also, Composer will only do an update if it sees that the version number for a package has changed, so I would also have to manually edit the my packages composer.json and mess with the versioning just to get the development environment to update. And this would have to happen EVERY time I hit save.

Seems like the workflow should be more obvious to me. What am I missing here? It's important that I use Composer in my local development environment so that other dependencies are properly loaded and I obviously want my package to stay in a cloned git repository so that I can push changes.

p.s. - Assume my package is non-framework-specific. Not specific to Laravel or Symfony, etc. Just a generic PHP package.

Answer 1

The obvious answer is:

You check out that package from its version control system, add the bugfixes or features you want, commit the result and tag the new version.

For best results this is done in isolation. Don't assume that there is an infrastructure of code around that package that would be usable. If you want to test that your package delivers the feature you intend, and can't test the package inside a bigger application, what remains is: Write automated tests for this. Or experience the unpleasant circle of coding, committing, tagging, updating, testing, still broken... more coding...