Hacker News Reader

Comment by msoad | Hacker News Reader

When node supports `import` how you'll import node modules?

I hope it works like this

    import {readFile} from 'fs';
    import {clone} from 'lodash';

rather than explicitly providing "correct" URL to the modules.

EDIT: edited the syntax.

View on HN

You'll be able to achieve that behaviour when node also supports destructuring.

    import { readFile, writeFile } from 'fs';
    import { clone } from 'lodash';

oops I forgot the braces! ok then, it's cool. I'm happy it does resolving to node_modules and all that automatically.

It's just syntactic sugar for `require`, mostly. The import mechanism should behave the same.

Just a nit, but that isn't destructuring. Named import syntax has several differences, since name aliasing uses a different format and you cannot nest or provide default values.

As I understand it, that still involves importing the whole file, rather than just the part you need. If that is an issue, lodash is parted out by method, so you can do this instead:

  import clone from 'lodash/lang/clone'

Not really. The destructuring syntax used in the imports is not the same as the standard array and object destructuring.

Section 15.2.1.16 of the current stable ES6 specification specifies how the import syntax is resolved, and it doesn't use destructuring.

P.S. Sorry too lazy to get a clickable link from the spec :P see http://awal.js.org/especser/#15.2.1.16 if you really wanna read it

Adding support for `import` will be a huge breaking change unless all existing packages have to opt-into it somehow. I don't think anybody has a good plan for this yet, apart from treating it as syntactic sugar for CommonJS.

The only problem are "default exports", i.e. overriding `module.exports` directly. In Node the exported names are just properties of the `module.exports` object but in ES6 the named exports are entirely separate from the default export. IIRC module.exports was not actually part of CommonJS although nowadays most people just use that word to mean "whatever Node does".

You can already use that syntax with Babel.

I wonder how that would work asynchronously. Or when the file is used from both the browser and node.

If you're building isomorphic code for the browser using webpack, you can quite happily chunk certain modules into separate bundles which will be loaded asynchronously when needed. It's pretty awesome.

ES6 imports are declarative, so dependencies are resolved and executed before the body of the module is executed. That means you don't conceptually have to think about whether your dependencies are loading synchronously or asynchronously.

Reply on news.ycombinator.com