I see -- interesting use case! Yes, you'd need to transform external module
declarations into local module definitions. But it should be pretty
straightforward: wherever you see
module m = "foo.js";
you replace it with
module m {
// contents of foo.js (recursively transformed)
}
(Incidentally, I've been working (off and on) on an API that exposes
SpiderMonkey's internal parser to JavaScript code, so that a JS program can
take a string, parse it as JS source, and get back a JS object representing the
AST. This should be helpful for building these kinds of tools.
https://developer.mozilla.org/en/SpiderMonkey/Parser_API
When I can find the time, I also want to write a JS pretty-printer that can
take one of these AST's and output JS source again.)
Dave
On Dec 28, 2010, at 11:17 AM, Kevin Smith wrote:
> Ah - that's much more elegant. Let me see if I can describe better though.
>
> I want to keep my library in source form as separate modules (one module per
> file, probably). I'll do development and testing that way. But I want to
> distribute my library as a single file. Presumably I'll need some tool to
> "bundle" all of the component modules together. I'm just trying to get a
> mental picture of what such a tool would have to do. It seems like we'd need
> to rewrite the module declarations (i.e. module b = "b.js";) but to what? Or
> would we?
>
> Kevin
>
>
> On Tue, Dec 28, 2010 at 1:51 PM, David Herman <[email protected]> wrote:
> I'm not quite sure I understand the scenario you're describing. Do you mean
> that we dump the contents of a.js and b.js into all.js and delete the first
> two files? In that case you can do:
>
> // all.js:
> export module a {
> export module b {
> // original b.js contents ...
> }
> // original a.js contents ...
> }
>
> But I'm not sure if I'm getting what you want the example to be.
>
> Dave
>
> On Dec 28, 2010, at 10:41 AM, Kevin Smith wrote:
>
>> Sweet - I was hoping that the module wouldn't have to name itself.
>>
>> My next question has to do with bundling. Let's say I want to bundle a.js
>> and b.js into a single file, with the exports of a.js providing the exports
>> of this bundled "thing". I suppose I could wrap both of the individual
>> modules something like this:
>>
>> module a { /* a.js text */ }
>> module b { /* b.js text */ }
>>
>> export a; // ? Not sure about this one
>>
>> But will the runtime know how to correctly resolve the (module b = "b.js";)
>> that comes from a.js? Or will that declaration have to be rewritten?
>>
>>
>>
>> On Tue, Dec 28, 2010 at 1:30 PM, David Herman <[email protected]> wrote:
>> There's some flexibility built in to the system via module loaders. The
>> "filesystem modules" example is hypothetical; it assumes a built-in module
>> loader that maps files available on the filesystem to corresponding
>> pre-defined, nested modules.
>>
>> On the web, you would do almost as you suggest:
>>
>> > // a.js
>> > module a
>> > {
>> > module b = "b.js";
>> > }
>>
>> except that a.js doesn't name itself; it's named by the script that loads it:
>>
>> // a.js
>> module b = "b.js";
>> ...
>>
>> // b.js
>> ...
>>
>> // project.html
>> ...
>> <script type="harmony">
>> module a = "a.js";
>> </script>
>>
>> Dave
>>
>> PS I will be updating the wiki pages soon to reflect some of the
>> finer-grained details and tweaks I've made to the design based on my
>> experience prototyping modules in Narcissus
>> (http://github.com/mozilla/narcissus). I'll ping the list when the pages are
>> updated.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
