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

Last publish breaks webpack build. #24

Closed
kevinbror opened this Issue Sep 5, 2017 · 9 comments

Comments

7 participants
@kevinbror

kevinbror commented Sep 5, 2017

It seems that the last publish of this commit d635b89 broke d3 for the browser. I have an angular 1.5 app that uses d3 and since d3 was updated to require 1.0.6 of this package, I get this error when trying to load the app after building:


XMLHttpRequest.js:15 Uncaught Error: Cannot find module "child_process"
    at webpackMissingModule (XMLHttpRequest.js:15)
    at Object.eval (XMLHttpRequest.js:15)
    at eval (XMLHttpRequest.js:622)
    at Object.<anonymous> (bundle.js?version=13.1.3:10487)
    at __webpack_require__ (bundle.js?version=13.1.3:20)
    at eval (d3-request.node.js:3)
    at Object.<anonymous> (bundle.js?version=13.1.3:10481)
    at __webpack_require__ (bundle.js?version=13.1.3:20)
    at eval (d3.node.js:25)
    at Object.<anonymous> (bundle.js?version=13.1.3:10343)
    at __webpack_require__ (bundle.js?version=13.1.3:20)
    at eval (dashboard.timelines.controller.js:26)
    at Object.<anonymous> (bundle.js?version=13.1.3:10319)
    at __webpack_require__ (bundle.js?version=13.1.3:20)
    at eval (dashboard.timelines.directive.js:14)
    at Object.<anonymous> (bundle.js?version=13.1.3:10295)

I have not been able to figure out which dependency update in the commit is causing this yet, but I figured I'd post this first. Reverting to d3 4.10.0 is a temporary workaround, since it requires 1.0.5 of d3-request.

@mbostock

This comment has been minimized.

Member

mbostock commented Sep 5, 2017

This error occurs because webpack is trying to consume code intended for Node rather than the browser.

In earlier versions of d3 (and d3-request; see d3/d3#3138) the browser field of the package.json pointed to a UMD bundle intended for browsers, whereas the main field pointed to a CommonJS bundle intended for Node. In cases where the code did not depend on any browser-specific functionality, as is the case with most D3 modules, there was no browser field and the main field pointed to a UMD bundle suitable for both Node and browsers.

The browser field was never intended to support bundlers; it was to provide short URLs for unpkg. The only supported entry point for bundlers is module, which points to the ES modules (and assumes a browser environment).

Alas, unpkg’s use of the browser field conflicted with Browserify and other bundlers that use this field to indicate a CommonJS bundle that may need shims for Node APIs not available in browsers, so unpkg is switching to a new unpkg-specific field, unpkg (see unpkg/unpkg.com#63).

If you want to rebundle D3 using webpack, or another bundler such as Rollup, you must configure it to consume the module entry point, which should be the default behavior of resolve.mainFields now that the browser field is gone.

@mbostock mbostock closed this Sep 5, 2017

@kevinbror

This comment has been minimized.

kevinbror commented Sep 5, 2017

Got it thanks!

@pmuellr

This comment has been minimized.

pmuellr commented Sep 12, 2017

Seems like this is still an issue w/browserify, which I guess must be dependent on the browser entry in package.json.

We just upgraded to 1.0.6, and found that we were getting the node version of d3-request instead of the browser one, then chased the issue down to here.

I just hacked the d3-request/package.json in my node_modules to add back

"browser": "build/d3-request.js",

then rebuilt w/browserify, and it looks like it picks up the browser version instead of the node one.

Perhaps there's something wrong in our build, or some option I can use w/browserify to work around this, but ... not obvious to me ATM.

My guess is that this will hit more people using d3-request via browserify ...

@mbostock

This comment has been minimized.

Member

mbostock commented Sep 12, 2017

I think if you’re using Browserify, you’ll also need Babelify so that you can consume the ES modules rather than trying to re-bundle the generated UMD.

@joeldouglass

This comment has been minimized.

joeldouglass commented Sep 14, 2017

Anyone figure out how to configure Browserify to use the module entry point? We're using Browserify/Babelify and have recently run into this same issue.

@nwshane

This comment has been minimized.

nwshane commented Sep 17, 2017

In case anyone is having this problem with webpack version 1, you can add 'module' to the front of resolve.packageMains as a workaround. See this issue: gatsbyjs/gatsby#2107 (comment)

whelmich added a commit to Frontwise/mim-graph that referenced this issue Nov 9, 2017

Lock d3 version
Prevent error caused by d3: d3/d3-request#24
@Sheparzo

This comment has been minimized.

Sheparzo commented Nov 21, 2017

It seems to me, based on comments here and create-react-app issue 3166 that the latest D3 may not be compatible with a non-ejected create-react-app. Can anyone confirm this?

@mbostock

This comment has been minimized.

Member

mbostock commented Nov 21, 2017

I don’t support webpack, but I am surprised it doesn’t work by default; it’s my understanding that webpack should prefer the module entry point (over the CJS bundle targeted at Node).

@amenadiel

This comment has been minimized.

amenadiel commented Feb 8, 2018

If you want to rebundle D3 using webpack, or another bundler such as Rollup, you must configure it to consume the module entry point, which should be the default behavior of resolve.mainFields now that the browser field is gone.

You'll need to explicitly configure webpack resolve.mainFields as ['module', 'jsnext:main', 'main']. That what I did in a project that needed webpack. Wouldn't have used webpack otherwise.

deepakprasanna added a commit to tarkalabs/react-d3-cloud that referenced this issue Mar 6, 2018

Locking d3 version.
Facing this issue currently d3/d3-request#24.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment