import script --> .esm

Kevin Smith zenparsing at gmail.com
Wed Sep 10 11:55:53 PDT 2014


>
>
> Why would it be a terrible idea to read the package.json as part of a
> server-based import mechanism?
>

Architecturally, it should be possible to write self-describing programs.
 Configuration files are good for tools (e.g. package managers and
compilers) and application settings.

Node currently uses "package.json" to find the module entry point: the
so-called "main" module.  But with ES6 modules this is unnecessary.  We can
simply have a "default.js" file at the folder root which looks like this:

    export * from "./lib/my-entry-point.js";

This accomplishes the same thing without having to parse JSON.

Also, we want to avoid having an explicit opt-in to the new module system.
 _Nobody_ wants to have to do this:

    {
        es6module: true
    }


>
>
>>
>> - If some folder that might be a "package" contains a "default.js" file,
>> then load it as an ES6 module/package.
>> - Otherwise, use the old-school algorithm (package.json or index.js).
>>
>
> Interesting idea, but there may be backwards-compatibility issues.
>

If a legacy package has a "default.js" file at it's root, then it will be
loaded as an ES6 module, causing an error.  But:

1.  Old clients would be unaffected:  `require` would not attempt to load
ES6 modules.
2.  For new clients, there is a workaround:  the client can just use
`require` until the package is fixed upstream.
3.  I did some scanning of NPM packages and it appears quite difficult to
find packages with "default.js" at their root.  I think I looked at the top
500 packages and didn't find any instances, although I need to re-check
that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/e98e0b8a/attachment.html>


More information about the es-discuss mailing list