import script --> .esm
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:
>> - 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss