On 10 September 2014 19:18, John Barton <[email protected]> wrote:
> > > > On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford <[email protected]> > wrote: > >> 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`. >> > > I don't think these are the same problem. Existing JS, AMD and CommonJS > can be parsed by the same parser, the ES6 Script parser. They can't be > parsed by the ES6 Module parser. It is a problem, just not the same as > this one. > > >> >> 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. >> > > One of the purposes of having modules in ES was to unify the module work > in mode and browser. Having two or more incompatible meta-data solutions to > this simple problem will defeat that goal. > Yes - we need to use meta-data solutions that can be cross-compatible. > > >> >> 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? > > jjb >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
