potential issue: dependency conflicts

[christabor]

One thing that hasn't yet come up, but most certainly will with the nature of having many different libraries all abstracted into one configuration, is the notion of dependency management and conflicts.

While there is a way to manage dependencies across charts, it assumes they always work with whatever version is specified in the settings.

While this is an ideal scenario, it is not likely to be the case forever. A particular example this comes up for is the change from d3 to d3.v4 - a fairly drastic api change that may break many libraries that have not made the jump yet. Also, ones that have, now have to have their versions pinned backwards in order to work w/ the rest.

A few options:

1. Multiple copies of a file loaded, for different versions (this likely creates a ton of bloat and potential namespace conflicts.)
2. Ignore ones that aren't up to snuff - e.g. manually testing and just filtering out those that don't stay up-to-date
3. Let the user choose (this kind of makes the idea of abstracting over this junk less useful though)

At this point in time, I'm inclined to pick 2, as it allows best code quality, no extra code, and really no change outside of more testing that needs to be done per version (which is somewhat necessary anyway).

I'm leaving it up here for now as it hasn't explicitly come up, but would be nice to have thought through to some extent when it eventually does.