Add change feed / webhook API

[ry]

@coreybutler
https://x.com/goldglovecb/status/1909638974802387128
https://github.com/npm/registry-follower-tutorial

[coreybutler]

I'm sure there are many use cases, but to clarify my request, I am interested in any kind of push-driven change feed we can monitor.

We are building a notification platform for developers that aggregates many different kinds of updates. Currently, we're using the npm change feed to capture module updates, which are relayed to our processing server via HTTP reqs (basically a big webhook receiver). We heavily process these and distribute notifications to users when relevant to them.

We'd love to incorporate JSR into this flow. Ideally, I think we'd register a webhook to receive all JSR module updates. I anticipate that as JSR grows, this could potentially present a scaling challenge. In our case, it's not absolutely critical to receive the update immediately/every second. It would be fine if updates were batched, say every 5-15 minutes, or some reasonable interval. The appeal of this approach is simplicity: we only need to setup an HTTP server to receive requests.

I'm only presenting the above as initial thoughtwork. I'm keen on any kind of solution and I'm open to discussing this topic in more detail. I originally proposed this to some early Deno DevRels (who may have moved on by now) on Twitter. I remember @bmeck chimed in on one of them that Socket.dev may have an interest in something like this as well.

[crowlKats]

I think these are things we could provide updates for:

• package created
• package archived
• package version published
• package version yanked
• package version deleted
• scope member added
• scope member left

let me know if there is anything else more granular that you would want to have

[coreybutler]

@crowlKats At first glance, that seems comprehensive. Is archiving essentially deprecation?

Would version publishing updates include license data (jsr.json)? I'd be interested in knowing if a license changes, but we could track the diff ourselves if the data is available.

[crowlKats]

Is archiving essentially deprecation?

archiving is the same as on github; so becomes read-only. so yes, it can be seen as deprecation, though a package can be unarchived

Would version publishing updates include license data (jsr.json)?

I think we could be able to provide that info, though not entirely sure right now

[coreybutler]

As I read the docs a little more carefully, I came to the realization that yanking is more aligned with what I was considering deprecation. Associating archiving with GitHub's made sense. There's probably some conceptual cross-over between those, but since both yanking/archiving would be available, it seems to cover the use case.

[wojpawlik]

Make sure to add a "npm tarball ready" event to simplify dual publishing /cc @crowlKats @KnorpelSenf

[KnorpelSenf]

I like the idea of having an event for when the npm tarball can be downloaded, but I don't think it should be used for dual publishing. That's better done in CI with a script that can build the tarball directly (after #525).

[crowlKats]

@KnorpelSenf @wojpawlik FYI dual publishing is now less relevant with recent developments: #1029

[KnorpelSenf]

That's so cool, I didn't know this