import script --> .esm

Guy Bedford guybedford at gmail.com
Wed Sep 10 14:43:16 PDT 2014


I think the point I was trying to originally make was that if you want to
take full advantage of the loader, you don't want to, in the long run,
treat CommonJS as a global script, running the NodeJS loader and System
loader both side-by-side, you want to be able to unify on a single loader.

When you load CommonJS through the loader, your problem of module or global
becomes one of CommonJS or ES6 module in the scenarios you are looking at.

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

>
>
>
> On Wed, Sep 10, 2014 at 11:28 AM, Guy Bedford <guybedford at gmail.com>
> wrote:
>
>> But within that you would also need a distinction of CommonJS or global
>> as well?
>>
>> One way might be to set up configuration to know which module names are
>> of which format:
>>
>> ```
>> System.metadata['test/*'] = {
>>   format: 'global'
>> };
>>
>> System.metadata['src/node/*'] = {
>>   format: 'cjs'
>> }
>> ```
>>
>
> The property of "which parser is appropriate" applies to a file, rather
> than a directory. Thus I could imagine:
> ```
> System.metadata['\.js$'] = {
>   format: 'module'
> };
> System.metadata['\.jsm$'] = {
>   format: 'global'
> };
> ```
> This strategy would allow module loaders to paper over the differences
> created by not having a standard extension.
>
>
>> Of course this mechanism doesn't exist by default - but you can create it
>> easily with the loader hooks in just a few lines.
>>
>
> This is equally true for many features added to ES6.
>
> jjb
>
>
>>
>> On 10 September 2014 20:14, John Barton <johnjbarton at google.com> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford <guybedford at gmail.com>
>>> wrote:
>>>
>>>> On 10 September 2014 19:18, John Barton <johnjbarton at google.com> wrote:
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> What more can I say? Some files need to be parsed as Script and some
>>>>> as Module.   Sometimes they are in the same project and sometimes in the
>>>>> same directory.  They work on browser and node.
>>>>>
>>>>
>>>> For Traceur, the default interpretation is as Module, so it sounds like
>>>> you want a way to indicate files which break this rule and need to be
>>>> interpreted as Script?
>>>>
>>>> Can you give an example of a type of file this would apply to?
>>>>
>>>
>>> Every file in test/ that does not end in module.js (and by extrapolation
>>> every file in every existing test suite based on mocha, jasmine etc).
>>> Every file in src/node/ (and by extrapolation every pre-es6 node file).
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> jjb
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/05095b10/attachment.html>


More information about the es-discuss mailing list