Introducing hooks: get notifications of npm registry and package changes
blog.npmjs.org
blog.npmjs.org
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.
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).
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?
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 :)
(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.
that being said, it turns out that the semver handshake the community does works Most of The Time, so if it is a trusted dependency it wouldn't be that dangerous. assuming you also had tests-dependent deploy, the tests would catch the break.
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.
But, I guess you could set up a whitelist for internal modules that your own org manages to propogate uptades up to deployment.