Skip to content
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

Usage from node v8.5.0+ with --experimental-modules #33

Closed
dandv opened this issue Jan 8, 2018 · 3 comments
Closed

Usage from node v8.5.0+ with --experimental-modules #33

dandv opened this issue Jan 8, 2018 · 3 comments

Comments

@dandv
Copy link
Contributor

dandv commented Jan 8, 2018

I'm trying to use the module from node v9.3.0 as shown here, but I get

The requested module does not provide an export named 'csvFormat'

$ cat index.mjs
import {csvFormat} from "d3-dsv";
$ node --experimental-modules index.mjs 
(node:9652) ExperimentalWarning: The ESM module loader is experimental.
SyntaxError: The requested module does not provide an export named 'csvFormat'
    at ModuleJob._instantiate (internal/loader/ModuleJob.js:84:17)
    at <anonymous>
@mbostock
Copy link
Member

mbostock commented Jan 8, 2018

Please read my comment on the linked issue.

@mbostock mbostock closed this as completed Jan 8, 2018
@dandv
Copy link
Contributor Author

dandv commented Jan 8, 2018

Pardon me for being dim on this, but shouldn't d3-dsv want to be usable directly from Node, without having to import any other module? I'm new to --experimental-modules, but published one that can be used just like that after asking on SO how to provide both native ES6 modules and backwards CommonJS compatibility.

@mbostock
Copy link
Member

mbostock commented Jan 8, 2018

d3-dsv is usable directly from Node, whether or not you choose to enable --experimental-modules. However, --experimental-modules still limits you to CommonJS interoperability with d3-dsv; you must either continue to use require to load d3-dsv, or import the entire d3-dsv module as the default export:

import d3Dsv from "d3-dsv";

This is because --experimental-modules is hamstrung: it will only load ES modules if the imported file has the extension .mjs, and its CommonJS interoperability is limited to loading the entire module as the default export.

Unlike most other ES module loaders, --experimental-modules does not observe the module entry point in the package.json. So with --experimental-modules you are still consuming d3-dsv’s UMD bundle as defined in the main entry point.

This limitation is why I recommend using @std/esm. Unlike --experimental-modules, @std/esm observes the module entry and allows you to consume ES modules using the standard .js file extension. It also provides better CommonJS interoperability, allowing you to import named symbols from CommonJS modules rather than being limited to the default imports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants