couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <>
Subject Re: CommonJS in map and reduce
Date Mon, 20 Sep 2010 15:53:58 GMT
Great writeup.

The only thing I think it's lacking is how the require namespaces will

So, refresher, require('foo') means import a module that is a top level
attribute in the design doc named "foo". Basically the commonjs module
namespace is scoped to the ddoc root. This will stay the same for require
outside of map/reduce.

In map/reduce all we'll do is re-scope the root namespace for require to the
ddoc "views" attribute.

All the "relative" imports, like require('./module'), will work the same but
we'll probably have some safe guard from doing '../../../' to get out of the
views sandbox.


On Mon, Sep 20, 2010 at 4:55 PM, Chris Anderson <> wrote:

> Devs,
> Mikeal and I were talking and we came up with a sane way to do
> CommonJS in map and reduce.
> Refresher: we don't have CommonJS require there now because the
> current CommonJS implementation is scoped to the whole design doc, and
> giving views access to load code from anywhere in the design doc would
> mean we'd have to blow away your view index anytime you changed
> anything. Having to rebuild views from scratch just because you
> changed some CSS or a show function isn't fun,so we avoided the issue
> by keeping CommonJS require out of map and reduce altogether.
> The solution we came up with is to allow CommonJS inside map and
> reduce funs, but only of libraries that are stored inside the views
> part of the design doc.
> So you could continue to access CommonJS code in, from
> your list functions etc, but we'd add the ability to require CommonJS
> modules within map and reduce, but only from design_doc.views.lib
> There's no worry here about namespace collisions, as Couch just plucks
> views.*.map and views.*.reduce out of the design doc. So you could
> have a view called "lib" if you wanted, and still have CommonJS stored
> in views.lib.sha1 and views.lib.stemmer if you wanted.
> We could allow CommonJS modules to be stored anywhere in ddoc.views,
> but I think it will simplify the implementation to enforce that they
> be stored in views.lib -- if people think that is too restrictive,
> please speak up now, otherwise I'll start to implement this.
> Chris
> --
> Chris Anderson

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message