The current situation, technically speaking, is that Snap has no official sessions package; but that will be changing in 0.6.  The sessions package that will be part of 0.6 does, I believe, use your clientsession package, unless that's changed since I last looked.

(I happen to be maintaining my own alternative package for typed sessions, which has two backends -- one using server-side state, and the other using your clientsession package.  But that's not an official part of Snap.)

Your cookie package is not likely to be useful for Snap, since parsing and rendering of cookie-related headers is already included in snap-core (and, I think, belongs there; it's a rather central part of HTTP; if we parse any headers at all, we ought to include cookies).

As for http-only, I definitely think it's a good idea, in pretty much all cases where cookies are used to pass through server-side state.  The kinds of cookies generated by clientsession are not really vulnerable to cookie-stealing attacks anywa due to the encryption that goes on, so it's really just an extra layer of security.  But the same encryption guarantees that there's no possible use for trying to access and read those particular cookies in JavaScript, so adding the http-only flag doesn't actually prevent anything useful, and there's no reason *not* to do it.