ES Modules: suggestions for improvement

Isaac Schlueter i at izs.me
Fri Jul 20 21:23:42 PDT 2012


Sorry for my long delay in responding.

On Fri, Jun 29, 2012 at 4:33 PM, David Herman <dherman at mozilla.com> wrote:
>> var fs = require('fs')
>> // no path here...
>> function notCoveredByTests () {
>>  fs.open(path.resolve("yabbadabba"), ...)
>> }
>
> Right.
>
>> How would any of this solve that?
>
> Because `path` is unbound, and static variable checking reports that as an error.

And this works because modules don't share global namespace with one
another?  (If they do share global space, then how would the static
checker know that it won't be assigned to a global 'path' by that
time?)


> I'm going to mull this more. I agree it's a worthwhile goal. But I'd like to find a way to keep the syntax as lightweight as possible and yet not interfere with static resolution.

Sounds good.  I'm interested in what you come up with.


> But we should not force this style on programmers.

It's not forcing anything on programmers.

If you want to export a bag of functions, then put the functions on an
object, and export the object.

It *is* making it trickier to figure out how to add types and macros,
but I'm less excited about those features than I am about making our
existing problems easier to solve.


> Even Node itself does not adhere strictly to that style -- look at the 'path' or 'fs' libraries, for example.

I consider that a mistake.  And even there, there's a single "exports"
object that methods are assigned to.


> Same with the ES standard library: Math and JSON are both multi-export (pseudo-)modules that just export functions.

They export a single object that has functions attached to it.
Math.pow(), JSON.parse, etc.

export { parse: parse, stringify:stringify }


> In these cases, there's no natural data abstraction needed, no class or object with methods, just functions. To quote John Carmack, "Sometimes the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function."

The Carmack quote is exactly why "export one thing" is so important.
Most modules should be a single function; not several things, not a
collection of utility methods.


>>> Moreover, it would be hostile to adding static constructs in the future, such as macros, that can be exported from a module.
>> Can you elaborate on that?
> It took me a few days, but I wrote up some rationale for static module resolution on my blog:
>
>     http://calculist.org/blog/2012/06/29/static-module-resolution/

At the risk of seeming like a little bit of a luddite, it seems weird
to me to make the "modules that export stuff" use case (which we have
now) less awesome, in favor of the "modules that exports macros and
types" use case (which is not a compelling problem right now).

Granted, we don't have that use case because it doesn't exist.  But
maybe it could be done in a different way that doesn't necessitate
multiple exports.


More information about the es-discuss mailing list