d3-selection dependency version issue with es6

In an effort to try and fix #1822 locally, I did an npm install --save d3-collection which installed v1.0.7.

This stopped the server from erroring out but instead I get this in the console:

Uncaught SyntaxError: The requested module './../../../d3-selection/src/index.js' does not provide an export named 'event' from d3compat.js:1.

Looking at the installed version of d3-selection it’s v2.0.0 where the event export seems to be gone. Downgrading with npm install --save d3-selection@1.4.1, event is available but it fails with Uncaught SyntaxError: The requested module './../../../d3-selection/src/index.js' does not provide an export named 'pointer' on the same line, which seems to be an addition of v2.0.0.

Not sure how this dep should be rectified.

[kum-deepak]

Yes I’m pretty sure the spec behavior is to fail hard, but it sounds like rollup can be configured to gracefully fail.

How about designing the code for a d3@6 environment and then including a compat-layer completely separate, only used in d3@5 (and lower?) contexts? It would then be included in the rollup build to produce the equivalent of the current output, if all consumption of this library is through a built rollup version anyway? Or there could even easily be two separate v5- and v6+ compiles. It would highlight the dependency structure a lot more clearly, the contract is very hidden right now.

I would propose to evaluate something like registering a dcjs namespace in globalThis and optionally registering things like adaptHandlers or nestHandlers there to override behavior. In the library you’d then check for those handlers and use if specified, otherwise default to latest (v6) behavior. This way users can use the rollup build as they do now but for es module approaches like mine I would not need any compat layer, if I did, I’d import the compat layer before the main dc.js library. That would again cause conflicting v5+v6 imports and to solve that the v6 behavior would have to be its own compat layer, forcing the user to always have a compat layer import, which might not be a bad thing, it’s definitely better than not working at all as it is now.

What do you think?

Thanks for analyzing possible approaches. I would like to add the following constraints:

• Over the years I have realized that dc is used by very less (programming) skilled users to extremely skilled people. The library should work without fuss for less skilled people. For these users, ideally, the default UMD distribution should work with d3@5 as well as d3@6.
• While using as es6 modules, I have a suspicion that it may not be possible to support both d3@6 and d3@5 transparently.
• We can, for now, assume module users to have, at least, moderate programming skills.
• Dynamic/conditional import (which is a function rather than a directive) might hinder the usage of standard UMD bundles, so, I think we should avoid it.
• Probably, it will be good to keep the es6 modules to work out of the box with d3@6 with instructions (possibly include an alternate module for d3compat, or, to include an additional module) to use it with d3@5.

@nomego, you have already analyzed it quite beautifully. Would you work on a PR where I can contribute as needed?

[nomego]

Yes of course it should work dynamically like today, where the dist version adapts dynamically to d3@5/d3@6. You’ve made an interesting built system where I assume it builds with @6 and fails for all things @5, but does so gracefully and converts d3 imports to d3 global references, causing it to “just work” in an @5 settings; clever. 😃

I made a PR for an example approach which needs some discussion and review in #1824, let me know what you think.