I’ve released d3@4.13.0 which fixes this problem for the last 4.x release (for now). But by the nature of this problem I can’t fix this for previous releases (such as 4.12.2).

I’m not going to pin dependencies in the D3 submodules—that would exacerbate the problem. I do keep this repo updated regularly, but there will always be a small amount of time that passes between updating a submodule and updating this module. (A monorepo would be better here, but I wanted something that could allow separate owners for separate repos.)

I suppose the answer is probably to not pin the dependencies in this repo, although that means that the d3 version is essentially meaningless if you are using node_modules rather than the generated UMD bundle. Still, I think that’s the right thing; there’s a variant of this issue that affects ES modules loaded from unpkg, for example.

This loads d3-selection@1.2.0, d3-transition@1.1.1:

https://unpkg.com/d3@4.12.2/index.js?module

But d3-transition@1.1.1 loads d3-selection@^1.1.0:

https://unpkg.com/d3-transition@1.1.1/src/transition/index?module
https://unpkg.com/d3-selection@^1.1.0?module

Which redirects to d3-selection@1.3.0:

https://unpkg.com/d3-selection@1.3.0/index.js?module

That said, when we unpin the D3 dependencies, then loading d3@4.x.y is always equivalent to d3@4 and loads the latest (v4) version of all D3 submodules, since there isn’t any code in the d3 package itself.

Since this is a fairly significant change, unpinning will be part of the 5.0 release.

I’ve released d3@4.13.0 which fixes this problem for the last 4.x release (for now). But by the nature of this problem I can’t fix this for previous releases (such as 4.12.2).

Ah great - thank you!

That said, when we unpin the D3 dependencies, then loading d3@4.x.y is always equivalent to d3@4 and loads the latest (v4) version of all D3 submodules, since there isn’t any code in the d3 package itself.

Since this is a fairly significant change, unpinning will be part of the 5.0 release.

Agreed this is a significant change so worth waiting until the major release. Thank you for considering it :-)

If it helps with deciding about tradeoffs, yarn has a resolutions feature that allows for forcing a particular package to be a specific version:
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

If users needed a particular version of a d3-* package (eg due to wanting to work around a bug accidentally introduced in a point release), then they could use resolutions in their package.json to override any ranges defined by the d3 package. This would be an improvement over the current situation, where d3 can only control the direct dependency versions and not these deeper down the graph.

I ran into something like this old issue with d3 v7 in a lerna / rollup monorepo. It might be worth recording the solution here.

We seemed to be doing everything right, with careful use of individual d3 modules and only one version of d3-selection present, but still the transition function was not mixed in.

In fact the individual module imports were the problem. We had some views where d3-selection and d3-transition were both imported, but others where we only used d3-selection. If the first import call only pulled in d3-selection then that version would be held by rollup, and any later import of d3-transition would modify a different version of selection that we never saw.

The simple solution was to create a wrapper and ensure that selection was always modified upstream:

import { transition } from 'd3-transition';
import { select, selection } from 'd3-selection';

export {
  transition,
  selection,
  select,
}

Our views import select and transition from this intermediate package, and all is well.

This is not a d3 problem at all but the result of our own overcomplication. All the same, @mbostock, the side-effects of transition are anomalous. Would you consider including an integrated 'selection with transition' package in a later release?