>
>
> 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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
