
Introducing hooks: get notifications of npm registry and package changes - steveklabnik
http://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm
======
koolba
> If you have a paid individual or organizational npm account, you can start
> using hooks right now.

Okay that eliminates the vast majority of npm users.

> Each user may configure a total of 100 hooks, and how you use them is up to
> you: you can put all 100 on a single package, or scatter them across 100
> different packages.

Only a hundred even with a paid account? That's pretty light.

I'm not a big fan of vendor lock in but this is the type of thing that would
be nice to have as a public service on SNS. Call it a "NaaS" (Notifications as
a Service). It could be as simple as an SNS topic that allows for public
subscriptions with subscribers paying their usage bills (which honestly would
be tiny if not zero).

I suppose that wouldn't handle the the private repo situation (since you
wouldn't want to publicize events regarding them) but for the majority using
public repos it'd be a win.

~~~
ag_dubs
we're still playing around with how many hooks to give each account- and we're
definitely open to increasing it. this is why we're releasing in beta.

as for it being paid, our registry is super expensive to run, so we're looking
for ways to make money to support it. this is one way to encourage people to
pay for their accounts. this also keeps our prices super low (we start at 7$ a
month).

~~~
koolba
> we're still playing around with how many hooks to give each account- and
> we're definitely open to increasing it. this is why we're releasing in beta.

Makes sense. I can imagine that if this was released to everybody,
immediately, and people set up their CI servers to auto update dependencies on
hook, and leftpad got updated, that'd be a serious thundering herd.

> as for it being paid, our registry is super expensive to run, so we're
> looking for ways to make money to support it. this is one way to encourage
> people to pay for their accounts. this also keeps our prices super low (we
> start at 7$ a month).

+1 to telling it like it is. I definitely get way more than $7/mo of value out
of npm.

Are the costs of npm public? Is it mostly bandwidth costs for transferring the
tarballs?

~~~
ag_dubs
> a serious thundering herd

hehe yup, def want to avoid that

> Are the costs of npm public? Is it mostly bandwidth costs for transferring
> the tarballs?

the costs aren't but that's an interesting idea. i'll bring it up with the
team.

and as for the origin of the cost, transferring the tarballs is a big part but
there are other parts of the infra that are also 'spensive. there are a lot of
packages, and a lot of users, and a lot of downloads. we're working on
reducing the cost of the registry at the same time as trying to increase
revenue- hitting the problem from both sides :)

------
Kequc
I haven't been using npm for a hugely long time, but every time I push out an
update to one of my packages it sees a boon in downloads. Then that trails
off. I assumed there was already a system in place that more or less keeps
people up to date.

~~~
steveklabnik
[https://greenkeeper.io/](https://greenkeeper.io/) serves that kind of
function.

~~~
ag_dubs
greenkeeper uses the follower ^__^

------
xg15
> You can use hooks to trigger integration testing, _trigger a deploy_ , make
> an announcement in a chat channel, or trigger an update of your own
> packages.

(emphasis mine)

I'm not very experienced in node.js development, but wouldn't automated
deployment whenever a dependency changes be a really bad idea? Especially
considering the issues with dependencies breaking in npm from the not-so-
distant past.

~~~
dragonwriter
> I'm not very experienced in node.js development, but wouldn't automated
> deployment whenever a dependency changes be a really bad idea?

Presumably, you'd want to trigger testing _and then_ a deploy, rather than
just triggering a deploy, but if you have fully-automated testing, there's no
reason not to include a deploy after testing as part of your triggered action.

You could, if you don't have fully automated testing, trigger a deploy to a
non-production server automatically, and then after whatever manual validation
you do on that server, manually deploy to production.

So, there's probably use cases for triggered deploys, but you don't want to do
it willy-nilly.

