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:
- Make a new workbench package the artisan way just to get set up
- Ensure composer.json is fine and commit and push it somewhere
- Remove the workbench folder
- 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
- 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.
