Don't patch d3-selection and d3-transition globally

[Gregor Aisch]

We recently ran into a problem where we had the following scenario: Module A was using d3-jetpack and d3-selection, and it was also importing module B which was using d3-jetpack and d3-selection. But it turned out that if B is importing a different version of d3-selection than A, but both are using the same version of d3-jetpack, only one version of d3-selection got patched (the one B was using). So all the imports from d3-selection in A did not have the jetpack patch.

There is really no good way to fix this from the outside so I think we should fix this here. I see two possible strategies:

1. The consumer module passed the selection and transition objects (or their prototypes?) to a sort of initialize() method exported by d3-jetpack:

// module A
import { selection, select } from 'd3-selection';
import { transition } from 'd3-transition';
import { initJetpack, drawAxis } 'd3-jetpack';

initJetpack(selection, transition);

2. d3-jetpack exports the stuff from d3-selection and d3-transition:

// module A
import { drawAxis } from 'd3-jetpack';
import { select } from 'd3-jetpack/selection';

Since I am nowadays bundling all my code using rollup anyway I think I am leaning to option 2.

[Adam Pearce]

I could live with either. I think both will work fine with a script tag; we should check how awkward observablehq usage is.

Could we copy what d3-transition does? @Fil, I haven't looked closely at the implementation or what happens in a similar situation—any tips?

Do you want to switch to this and d3v6 in one breaking change?

[Philippe Rivière]

transition attaches itself to selection here https://github.com/d3/d3-transition/blob/master/src/selection/index.js;
d3-selection is defined as a peer dependency in https://github.com/d3/d3-transition/blob/master/package.json#L44

’s all I can say.