Understand all the stripes-building scenarios, and their implications for dependency management

At present, Stripes is built from a set of nine packages (each named stripes-something), each of which is separately maintained, versioned and released. In some respects this flexibility and independence is valuable, but it also creates many opportunities for incompatibilities. Accordingly we are considering several approaches to mitigating this:

• The creation of a dependencies-only stripes-framework package to maintain dependencies on all the lower-level components (STRIPES-543)
• Moving to a monorepo in which a single git module contains the source-code for all the stripes-* modules, and commits and PRs across those modules are atomic (STRIPES-503)
• Moving all of the Stripes foundation into a single NPM package.

What are the implications of such changes? To evaluate them, we first need to understand all the different valid development pathways and what they mean for compatibility between different versions of different bits of the code. Otherwise we will keep coming up with candidate approaches that will be great for scenario X, and only then realising they will make things worse for users of scenario Y. Just listing the scenarios would be a good start.

We will create a discussion document which aims to comprehensively survey all the different ways in which Stripes might be build, as a basis for reaching wide-ranging conclusions regarding what changes to make to how the various parts are managed.