In this last section, we'll think about the composition of large Flux applications from the point of view of packages. First, we'll make the case for a monolithic distribution of a Flux application, and the point at which this approach becomes untenable. Then we'll talk about packages, and how they help us scale up the Flux application development effort. Finally, we'll walk through an example of how this might work.
Anyone who has been caught in dependency hell knows that it's an unpleasant place to be. Generally speaking, we bring these issues on ourselves by relying too heavily on third-party packages. For example, we might use a couple components from a gigantic library, or we might use an exceedingly simple library for something we could have written ourselves. In any case, we end up with more dependencies than what's justified for the size and scope of our project.
Just because we're implementing a Flux architecture for our application...