Laravel app with package git workflow

Question

So I have a new GitHub repository in which my Laravel app lives.

Got this set up and working fine.

I wish to create a package for the app (and plan to make use of this in other projects) and therefore I've created a workbench using artisan.

I've also added another GitHub repository for said package to live in.

I've added /workbench to .gitignore so that my package development doesn't get committed to the Laravel app repo.

My question is, how do I set up git so that the package in workbench is tracked only by the repo that I've set up purely for the package?

Answer 1

This is a question with a very big answer. In short though, you don't need submodules. Just navigate to your package's directory in workbench and do a git init, that'll set a git repository up there for messing with code and pushing. If workbench is in your main app's .gitignore then the two shouldn't get in each other's way.

However, I found that developing on something within workbench didn't work out too well. First off, when your app is in 'workbench' mode the set up is very slightly different from normal. You'll probably not really notice this, but one large difference is that any packages that your package relies on in its composer.json actually override your main app's packages. I learned this the confusing and hard way when developing two packages (of which one relied on the other) in the same workbench app. The package that the second package relied upon wasn't actually being executed, as Laravel was seeing the files for it in the vendor directory of the second class. Very weird and hard to debug. Anyway, it's unlikely you'll have that exact problem, but it just goes to show that Laravel is in a different 'mode' when you're using the workbench.

Also it makes teamwork a little harder - it's kinda more sensible (though I guess not necessarily easier) to use a development package in composer rather than clone a git repo into workbench. I suppose this could be a case where submodules work for you. That said I've been stung by submodules in the past and refuse to go anywhere near them again, but maybe I'm being irrational there!

So my solution is to do this:

1. Make a new workbench package the artisan way just to get set up
2. Ensure composer.json is fine and commit and push it somewhere
3. Remove the workbench folder
4. Add your newly-pushed workbench package to you main app's composer.json, but ensure that you use a develop version (version constraint of dev-master, for example) - this makes composer download the full repository rather than just the absolutely necessary files
5. Now you can develop on the package directly in your vendor directory

Points/caveats:

• You must use PSR-based autoloading, as I don't think composer dump-autoload takes into account packages in vendor other than when first installed or updated with composer update, though I'm not 100% on that. Still, use PSR autoloading and it's all good.
• You can make changes to your files and you don't need to commit and do composer update or anything - it'll just use your files as you'd expect.
• However, if you change your composer.json file, you must commit, push and then do composer update, as composer will not recognise these changes. This could be changes to dependencies, autoloading rules or anything else that you will need to rely on with your app.

Bonus for teamwork is that everyone can do the same. composer require vendor/package dev-master will get them a git repository in their vendor/vendor/package/ directory.

---

This is all based on my personal experience though. Supposedly there's nothing wrong with the workbench and/or submodules, but I've had issues with both in the past, so I've given up on them. I don't really think there's one right way to do this.

Answer 2

It seems as though after more research, git submodules are my answer!