[2:57]<saikat> in the commonjs module spec, if i have file1 that does require(file2), and file2 does require(file3), does file1 have access to file3's exports? [2:58]<saikat> no, right? unless file2 exposes them? [3:03]<jbrantly> saikat: right (more or less) [3:04]<saikat> which part is less right? [3:05]<jbrantly> well, not entirely sure what you mean by "have access" is all. In order to load a module, you have to use the object returned by require. So I'm not sure how you expect file1 to have access to file3 unless it's through file2. [3:06]<saikat> ah right [3:06]<jbrantly> or unless file1 does a require of file3 [3:06]<saikat> file3 can't put things in the global namespace can it? [3:06]<jbrantly> basically, right [3:06]<jbrantly> its not supposed to :) [3:07]<saikat> ah ok, thanks =) [3:07]<jbrantly> there is a clause I believe.. *goes to look it up* [3:08]<jbrantly> "modules must use the "exports" object as the only means of exporting." [3:08]<jbrantly> but in reality most environments do have some form of global that can be accessed [3:21]<deanlandolt> exactly...these are secure*able* modules, not secure modules :) [14:03]<ashb> kriszyp: explain to me how you can fetch an entire package over HTTP when pointed at a directory/ ? [14:03]<ashb> (can't send emails at the moment for some reason) [14:06]<kriszyp> the point of specifying a directory/ is so that the module loader doesn't attempt to load an entire package [14:34]<ashb> then what happens when it comes across a file it doesn't have? [14:46]<kriszyp> it downloads it [14:47]<kriszyp> it definitely only works at runtime, but this can be done prior to the require call with static analysis [14:48]<kriszyp> and it might be helpful to explicitly indicate the limitations of specifying a directory in the spec, but it definitely works with an static analysis capable module loader (i have an impl)