Provide a combined `ampersand` module

I didn’t know where to post this (which is part of the point I’m trying to make here), so I just posted it in what I think is the most important Ampersand module.

One of Ampersand’s primary features is that it is a collection of modules that can be used independently, and that there is no big module necessary. While this is a good goal design-wise, it poses some practical problems for Ampersand users like me:

• My npm-shrinkwrap.json is currently 2300 lines long, 2000 of which are Ampersand. As someone who likes to be on top of all the dependencies of my production project, this scares me a lot. This is also not what one would expect from a ‘simple, no-magic’ framework. (Backbone.js only has underscore as a dependency).
• I seem to recall only upgrading specific ampersand modules once or twice, and yet the dependencies of all Ampersand modules combined are all over the place: some modules depend on underscore, some on lodash.*, and I also see some other dependencies that could (and might have been already) be replaced by lodash.*.
• Whenever I detect I need to upgrade a module, I’m too scared to do it these days. Especially if it’s a module that has some dependencies or dependents of other ampersand modules, I’m worried about what will break because of incompatibility, what other dependencies I’ll end up pulling in, etc. For example, I tried upgrading a module last week, but something somewhere else in Ampersand broke. I don’t know if it is actually a bug, or my own fault of incorrectly updating another module.
• It’s hard for me to keep track of what changed to which ampersand module; every module is upgraded independently, no changelog is kept, so i would have to go through all the git commit logs of all modules I indirectly depend on. This means I only update when I spent some time discovering a bug myself, which is too late.
• An extra problem in commercial settings is that each module’s dependencies (and subdependencies) need to have their license checked by legal teams. The size of the dependency tree in itself means this is a significant task, but this also makes it a hassle to update a single ampersand dependency, as it needs careful checking what the upgrade did, and whether it didn’t cascade other dependencies.

This is why I would like to have a combined ampersand module with all (or at least the most important ones with common dependencies) ampersand modules combined. Advantages:

• This greatly simplifies the dependency tree in a project using ampersand, and simplifies mental tracking of the ampersand dependency.
• Dependencies of Ampersand are maintained and updated in sync, so it’s easier to track those as well
• Upgrading ampersand feels much safer, as I know that anything breaking will be a problem with code, not some strange interdependency problem or something I did wrong.
• Keeping track of what changes in ampersand is easier, because I just have to look at the changelog / commit log / diff of a single project.
• It makes it easier to report global ampersand issues such as this one, as there is an all-encompassing issue tracker
• Probably not important, but combining usage may give a more accurate score on npm.js.
• I’m not an Ampersand developer, but I can only assume that this would make some aspects of developing modules (especially upstream ones) and figuring out bugreports easier.

I’m not sure what the easiest practical way to get to such a module is. Maybe a first step could be to hand-pick a combination of modules+versions that play well together and have similar dependencies, and use a script that combines all these modules into a single module that is maintained separately. This would solve many of my problems. However, I think ultimately it would be simpler to have a lodash-like setup, where a single module is chopped up into smaller modules and published for those who like that sort of thing.

An extra optimization (which would simplify the dependency tree even more) is to depend on lodash as a whole instead of dozens of small lodash parts which in turn depend on several other lodash modules. If size of unused dependencies is a concern, tree-shaking could get rid of the unused lodash parts in the future anyway?

[cdaringe]

yep, now i’m just outright in full support. keep bundle sizes lower, improve cross-dep deployments. i was short-sighted before, apologies. the recent npm unpublish fiasco, &-state upgrade version debacle, and lodash v3 => v4 bumps are all advocating examples.

@AmpersandJS/core-team, something to consider. long term, it would be nice to migrate to a lerna-like approach for version control & deployment.

[cdaringe]

@remko, ya, i’m opening up to the idea. needing to review other teams’ monorepo formal approaches some.