adds updates.metadata functionality

[rockbot]

Major questions:

1. when is the vdu checked when updates.metadata is called via a route? (It seems silly that the tests check the vdu after the update happens.)

2. How does one do integration tests on this code? Maybe I'm just missing a key piece of information, but how do we know that this code would be executed via /registry/_design/app/_updates/metadata/?

cc: @isaacs

[rockbot]

Thanks to @seldo, I have answered both questions!

Now making sure the code I need to work still, you know... works. :-)

[terinjokes]

@rockbot mind expanding on on those answers?

[rockbot]

@terinjokes

So, the important thing to understand (which I didn't before) is that this repo's entire purpose is to create the _design/app design doc. So when it's in couch, it does things that it doesn't necessarily do when it's not yet in couch (which we have to fake with tests). Thus:

1. the vdu is checked on every PUT request. In the tests, however, we have to force the vdu check. Doing it before or after (it seems) shouldn't really matter.

2. I've gotten the updated design docs up and running locally (you'll need to point _npm-registry-couchapp:couch to your local instance in ~/.npmrc), and am still testing to confirm that /registry/_design/app/_update/metatadata is where the magic happens, but I should have that answer for you before this pull request gets merged :-)

[rockbot]

have confirmed: /registry/_design/app/_update/metadata is where you want to PUT data for updates :-)

[isaacs]

1. The _updates function returns [doc, response]. That doc obj is passed to the vdu, and if it passes, then it goes into the database. The vdu is the last line of defense.
2. The best way to do integration tests is to add support to the npm client, and then follow the pattern of the various 01-adduser.js, 02-publish.js, etc. tests, and run some npm stuff and then make sure it has the desired effect on the server (and that unauthorized users aren't able to modify stuff!)

[isaacs]

I think the "name" is unnecessary here (though, it's also un-harmful, so whatevers.)

[isaacs]

LGTM. Also probably worth doing the {"field":null} to remove a metadata field, but feel free to skip that for now if it's a pita to do.

[rockbot]

So - having tackled it for a bit now, while conceptually a {"field": null} is easy, the implementation is, in fact, a bit more of a pita to do. :-/

let's discuss.

[isaacs]

Landed on master.

Should probably add additional bits to support setting repository and bugs and other simple object fields.