-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluate what would be involved in updating to the current version of d3 (v7) #15
Comments
This will depend on upgrading the rig to handle ES modules, but probably won't necessitate too much more on top of that. |
The rig has been (theoretically) updated to handle ES modules. Migration guides from D3: It doesn't look to me like there are real syntax/API problems for our graphics. I think we could proceed as follows:
|
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 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 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:
|
Perhaps unsurprisingly, the D3 project is not at all interested in fixing this bug, so we'll have to figure out other options. d3/d3#3532 |
Totally not understand why d3 package only support @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 |
No description provided.
The text was updated successfully, but these errors were encountered: