Open alykat opened 3 years ago
The rig has been (theoretically) updated to handle ES modules.
Migration guides from D3: V5-V6: https://observablehq.com/@d3/d3v6-migration-guide V6-V7 (release notes): https://github.com/d3/d3/releases/tag/v7.0.0
It doesn't look to me like there are real syntax/API problems for our graphics. I think we could proceed as follows:
d3-array@2
to d3-array@3
).Unexpected snag! D3 exports itself as ES modules, but still maintains a UMD build in the /dist folder for bundlers. However, while Browserify happily ignores the package.json and loads this file, Node itself does not: the "exports" key in the package.json doesn't mark it as public in a way that Node will follow. You can import
in Node, but you can't require
.
This is a problem because in our HTML, we sometimes use D3 that's ported from the client-side code to do templating. We need to require()
it, because we want modules to resolve from the graphics-js folder, not from the rig location, which is what import does (and this doesn't appear to be monkey-patchable).
We're going to file a bug with D3 and hold off on upgrading for now, but our eventual options look like this:
OR if D3 declines to fix the bug:
require()
for modules in EJS templates. You can still do basic Node processing for data in a template, but nothing requiring a library. This sucks but is sustainable long-termlocalRequire
in processHTML.js
, piping the file through Babel before passing it to Node This isn't terrible, but adds complexityrequire()
, that can handle both ES (via await import()
) and CJS modules, making sure that the pathing is correct for the graphics folder and not the host app. This is elaborate and probably fragile.Perhaps unsurprisingly, the D3 project is not at all interested in fixing this bug, so we'll have to figure out other options. https://github.com/d3/d3/issues/3532
Totally not understand why d3 package only support import
but not require
,
@thomaswilburn, thank you for the detail advice, we are creating a separate loading mechanism only to handle d3 package, and making it as kind of function-api, really uncomfortable
This will depend on upgrading the rig to handle ES modules, but probably won't necessitate too much more on top of that.