Monorepos and small dependencies are awkward!

[magnalite]

Splitting up a codebase into as many packages as possible is something we want to promote and make as easy as possible. Currently if you have a monorepo or are the only consumer of packages this is incredibly awkward! If you want to update a package which would otherwise just exist in your codebase you have to swap editor/git contexts, make the change, publish and then install back into the main codebase.

This is especially awkward right now as we don't have path dependencies so there is no convenient way to test a package works in the existing codebase. While it could be argued that a package should have its own well defined api, and so not need a consumer to know if it works, it is very common to want to test that package in a larger codebase. This will be partially relieved by path dependencies being added (#88).

This issue is however much larger than just needing path dependencies and can be broken up into multiple issues:

Supporting large monorepos

If you have a large monorepo with many discrete packages and you want to publish all of them then you need to update all the tomls to not use path dependencies before you publish. This sucks. I see a clean way to support this and would like to propose "publish-supported path dependencies".

If you have a package with a path dependency to another valid package then wally can "link" these packages at publish time. It can upload every linked package replacing the path dependency with the version that will be published. As long as every path dependency can be substituted for a version that will be published then the package collection is considered ok to publish. Monorepo development will then be simplified to editing whatever you want however you want and simply calling wally publish once at the repo root. No editing tomls or publishing packages individually required!

With that said there are some thing we would need to figure out first. For example how should versioning work? Should every package be pinned to the same version? Should we auto increment versions so you don't have to edit the toml of every changed package when you want to publish? How would we know if we should increment the major, minor or patch number?

tl;dr If a collection of packages use path dependencies to link to eachother and no external path dependencies exist then we can publish every package in one go and convert those path dependencies in the published versions. One monorepo, one publish command. Easy.

Editing a dependency

Wanting to edit a dependency is a very common use case. We can assist with supporting this by adding a new command wally edit <dependency>. This command would open the dependency in a convenient way to edit, let you perform those edits and test with the larger codebase, and then let you easily publish those changes.

I'm unsure exactly what the implementation of this command would look like but it could play very nicely with the above addition. I could see this command as auto converting that package to a path dependency (which could then auto publish when the root is published if the above is added) and moving it somewhere convenient (out of the managed _Index folder). It could then auto convert back from a path dependency if you choose to publish that package, however we would need to take care we only do this if the user doesn't want to keep it as a path dependency.

tl;dr wally edit <dependency> opens a dependency to perform edits, test with the larger codebase, and then publish conveniently.