import script --> .esm

Guy Bedford guybedford at gmail.com
Wed Sep 10 10:07:47 PDT 2014


The question of whether a file is a module or script is the same problem as
to whether a module is ES6 or AMD or CommonJS.

Moving it to the extension makes as much sense as having every CommonJS
module written as `script.cjs`.

We know that we need outside metadata to work out how to interpret modules,
and that the loader will have meta-configuration injection at some level,
not determined by TC39.

In NodeJS, this can be through `package.json` properties which inform what
module format the package is. In the browser, this could be a header, or
part of package configuration.

John, in your case specifically, it would be good to get more background to
understand what type of meta process is most suitable.

On 10 September 2014 17:30, John Barton <johnjbarton at google.com> wrote:

> A couple of months ago I tried out the suggestion by Yehuda Katz to use
> import syntax with special module specifiers to mean parse-as-script, do
> evaluate but do not produce a module.  The implementation worked well and
> now I want to put a version of this idea into Traceur.
>
> As soon as I started I ran it issues with the name. Obviously "legacy:" is
> ambiguous. "script:" looks like a URL, which I suppose was intended, but
> then we get into URLs in URLs.  Furthermore, the URL scheme is very
> cumbersome with a filesystem, you have to have some side-table or algorithm
> to match URLs to directories or filenames.
>
> I implemented postfix ",script", but that sure looks like an extension.
> Which is exactly what the semantics are: a file with a different datatype
> needing different processing. So it seems to me that the most honest naming
> would be some thing like ".ess".
>
> I would just implement that solution but I proposed a similar idea a while
> back to Traceur team I got a lot of pushback along the lines of "JS is one
> language".  Since then several Traceur users have asked for support to a
> non ".js" extension for loading modules, to be able to separate existing JS
> code in .js files from new module code in files marked with a different
> extension. Within Traceur's (mostly es6) code we have resorted to implicit
> marking-by-directory ("All code in src/node is script, not module") or with
> the wonderful extension of ".module.js" to mean "all the other files are
> script, but this one is module".  So it's JS-is-one-language with two
> incompatible, unmentionable dialects ;-).
>
> Finally, naming modules as .js and ES6 Scripts as .ess has the weird
> result that ES5 scripts (in .js files) would be processed as ES6 modules.
> That seems dumb. So naming the new things, modules, with a new extension
> makes more sense.  ".esm" seems like a obvious choice.
>
> I know this may not seem to be the most exalted of topics for
> standardization but the current choice of post-pending '.js' has real
> consequences for developers. Please consider this issue.
>
> jjb
>
>
>
> On Mon, Jul 14, 2014 at 9:57 PM, Yehuda Katz <wycats at gmail.com> wrote:
>
>> You could imagine a loader plugin that enabled:
>>
>> import "legacy:foo";
>>
>> Which would evaluate the module in a script context.
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/652c7d92/attachment.html>


More information about the es-discuss mailing list