D3 v4 - how to handle sub-modules?

[mike-north]

What's the plan for d3 v4? This may work for bringing in the whole library, but it might be useful for opting into particular submodules of the new repo.

It would be nice to avoid having a bunch of individual shims, like https://github.com/ivanvanderbyl/ember-cli-d3-shape for each submodule -- particularly when you consider the "nested addon" use case (i.e., addon1 requires d3-shape v1 and addon2 requires d3-shape v2)

cc: @ivanvanderbyl since he's using d3v4, and is well-versed in common usage patterns
cc: @stefanpenner since we're talking about nested addons, and I'm curious as to what he thinks the possible (and recommended) path(s) forward are

[brzpegasus]

I don't have any immediate plans for d3 v4 yet. Unfortunately my ability to sit down and code is extremely limited at the moment, at least until I return to work in September.

From a quick glance, it seems to me that https://github.com/ivanvanderbyl/ember-cli-d3-shape loads up all the d3 submodules, not just shape, and patches up the AMD modules to be compatible with Ember CLI's loader? Would be nice if the hacks weren't needed and we could use the AMD modules that d3 v4 provides out of the box in the first place.

[mike-north]

I don't have any immediate plans for d3 v4 yet.

How about giving myself and @ivanvanderbyl contributor access so we can take care of this for you. I'd love to see only one main "d3 shim" ember addon that the whole ecosystem revolves around.

A common sense approach might be to tag this with 3.0 and then start cracking on the new stuff as a 4.0 release

[ivanvanderbyl]

I'd be happy to do the leg work to make this happen.

I'm not sure of the current status of the D3 modules, but when I started authoring that addon they were using a type of universal module loader which was not compatible with Ember because Ember doesn't expose a 100% compatible AMD module loader, so the Funnel I built basically converts them to modules which Ember can load, then adds them to the vendor tree so you can easily import them as per the D3 v4 docs.

[brzpegasus]

I added both of you as contributors. I'll take care of the NPM portion when I can get access to a terminal later today.

Wish I could be of more help!

[ivanvanderbyl]

Thanks so much Estelle, I'll get it ready to cut a new release and have this replace my addon next.

[brzpegasus]

@ivanvanderbyl / @mike-north Added as owners to NPM.

[mike-north]

Awesome. Thanks estelle!

Ivan - I have some interesting "nested addon" cases that might make a good set of target use cases

A "d3 v3 only" library

where I need to constrain d3 to a particular version to support something built on top of it (https://github.com/levanto-financial/ember-nvd3-shim/blob/master/blueprints/ember-nvd3-shim/index.js#L6-L11)

blueprints/ember-nvd3-shim/index.js

  afterInstall: function() {
    return this.addBowerPackagesToProject([
      {name: 'nvd3', target: '^1.8.0'},
      {name: 'd3', target: '^3.0.0'}
    ]);
  }

An app that only needs part of the d3 v4 stuff

Your old shim made this work well, although I believe I still had the overhead of everything in my app. There's something to be said for explicitly opting in to submodules -- particularly when managing a lot of developers (easy to "contain" usage to a particular subset, if developers need to "opt in" to another module in a pull request).

An app/addon that wants to use d3 v4 as a complete library

Probably a very typical use case. imo this should still use submodules so we can take advantage of tree shaking and other "project svelte" initiatives in the future.

---

It feels like we might want to do the following

• Modify this addon's installation blueprint so that it installs d3 ^3.0.0 in consuming apps
• Tag a 3.0.0 release
• Create a v4 branch
• Move your stuff from the d3-shape shim over into this repo
• By default, all modules are installed
  • Nice to have: ability to "opt in" to particular submodules via a ember-cli-build.js option (i.e., array of module names, fall back to "all modules" if not specified)
• Tag a 4.0.0-alpha.1 and let's play with it.

[ivanvanderbyl]

Hey @mike-north — sounds like a good plan. I was actually thinking master => v3, then new master is v4. We'll cut a v3 release that matches the D3 version, publish that and move on to v4.

In my addon I've managed to make some assumptions about whether the addon is in another addon or an app, which means we don't need to install any other deps in the parent like we do with bower because it can work out which app to import to https://github.com/ivanvanderbyl/ember-cli-d3-shape/blob/master/index.js#L28-L45

I think there's a possibility that we could make this either include a version of D3 v4.x or use one installed in the parent, I'm just not sure which one takes precedence, Stefan probably has some idea :)

[mike-north]

Hey @mike-north — sounds like a good plan. I was actually thinking master => v3, then new master is v4. We'll cut a v3 release that matches the D3 version, publish that and move on to v4.

👍

[ivanvanderbyl]

Module opt-in is resolved in #8