fail to import d3

[skazska]

JSPM Version: 0.16.53

Transpiler Plugin(s): babel

Details:
installed d3 with jspm install d3

importing with import d3 from 'd3'; (all according to 'get started' template)

having error in console:
Uncaught (in promise) Error: (SystemJS) Node child_process module not supported in browsers.
Evaluating http://localhost:63342/jspm-packages/github/jspm/nodelibs-child_process@0.1.0/index.js

problem is in jspm-packages/npm/d3@4.12.2.js : module.exports = require("npm:d3@4.12.2/build/d3.node.js");
after changing it to
module.exports = require("npm:d3@4.12.2/build/d3.min.js"); it started to work

this is contained in jspm_packages/d3@4.12.2/build/packaje.json:
export var main = "build/d3.node.js"; <--- !!!!!
export var unpkg = "build/d3.min.js";
export var jsdelivr = "build/d3.min.js"; <--- !!!!!

there is some kind of related issue thread in d3 d3/d3-request#24

[skazska]

sorry, change module.exports = require("npm:d3@4.12.2/build/d3.min.js"); was not make it work actually it just eliminated error
in addition it is required to import it like import * as d3 from 'd3'; to make it work finally

[ffflabs]

You can do simply

import d3 from 'd3/build/d3.min.js';

without changing jspm-packages/npm/d3@4.12.2.js.

However @guybedford I believe that there should be a way to tell if jspm should use the main entry of the package.json or the module property. This could obey to certain conditions. For example:

• if transpiler is enabled, any package with a module entry should use that value as main, instead of main property.
• If a package has a module entry, use that when you import instead of require the module.
• If a package has a module entry, and you override its format to be esm, use the module entry.

In D3 package.json says:

 "main": "build/d3.node.js",
  "unpkg": "build/d3.min.js",
  "jsdelivr": "build/d3.min.js",
  "module": "index",
  "jsnext:main": "index",

Even if we override main to point at index, said module will import from every d3 dependency. In particular, when importing d3-request, it loads build/d3-request-node.js which in turn calls jspm_packages/npm/xmlhttprequest@1.8.0/lib/XMLHttpRequest.js which finally calls child-process.

If module property was taken as main for d3_request, it would use native browser's XMLHttpRequest. This means that using module instead of main should cascade for nested dependencies.

[aluanhaddad]

@amenadiel I've often thought about this scenario. I ran into the issue over a year ago with ESRI Leaflet.

It could be really valuable to have a setting for this, but how should it work?

1. How to determine precedence when there are overrides?
2. Which fields should be considered?
3. There are a lot of these properties... which ones count? "jsnext:main" has been around for a long time. "module" is fairly common. I'm now starting to see "es2015"...

[ffflabs]

Well, in webpack you can set which fields use as main as an array: ['module', 'jsnext:main', 'main'] and tries those fields in that same order. However, if a global config was added to jspm, it would complicate resolution flow.

For example, if a package.json had a module field, but had also a jspm entry declaring it's an AMD module, which one should prevail? There are other edge cases, for example if a library is a dependency for two others, one of them importing the module and the other one requiring the UMD build. There would be a race condition to fill up the SystemJS registry with the result.

Of course, this issue only manifests itself in cases like d3, where it's meant to be an ES6 package but declares a main property pointing to another file which often is an UMD built for compatibility purposes.