JSR: Building an Open Registry for the JavaScript Community

Hello, and welcome to JSR, building an open registry for the JavaScript community. So first off, I'm Leo. I work at Deno, and I'm also a maintainer of JSR. So I want to quickly see a sea of hands how many people know what JSR is. Okay, about a third. Fair. Good, good.

So, for the others that don't know, first let me introduce you. What is JSR? So JSR is a new JavaScript registry. It's similar to NPM, but it's not NPM. It supports TypeScript out of the box, which is not just a feature. It was a foundational technical decision that we wanted to have, because TypeScript is everywhere now, and publishing TypeScript to NPM is a bit of a drag. I'll get into that in a bit.

And then, well, as I said, it does not replace NPM. It lives alongside it. So you can still use your NPM packages when having dependencies in JSR. And it's compatible across different runtimes. So you can use it with Cloudflare workers, Deno, Node.js, Bun, and anything else that supports Node modules directories. And it also has built-in support by YARN NPM-PM, as recent, but not NPM, which we would like to change. And another feature point is that JSR is completely free and open source. So why did we build JSR? Well, the first reason is complexity. Again, publishing to NPM can be a bit too complicated. You have to set up TS config, you have to find the right settings, the target, et cetera. It shouldn't be like that. It's way too complicated. And we just wanted to work. Oh, whoops. Then we have innovation. NPM has stopped adding any new features, really. I mean, have you ever seen any recent changes to NPM? No.

The most recent feature, I think, was like two years ago it was something. But anything recent, there hasn't been, because they have stopped innovating. And the JavaScript ecosystem doesn't suit for that. The JavaScript ecosystem constantly evolves. There's a new framework like every week. And the ecosystem itself is moving fast. But the registry it lives on is not moving whatsoever, which is completely unacceptable.

Unlike NPM, which is owned by Microsoft, JSR is completely open. It's open source, it's driven by a community, and it has open governments as a core principle. Some additional features are tokenless auth, so you can just publish from GitHub actions without having to set up any tokens. It will just use OIDC and check with your GitHub user. Provenance, so it can prove that the person that published it actually is the person that published it. Documentation generation, which generates documentation automatically based on your typings and JS doc comments.

JSR is open for the reason that JavaScript is controlled not by a company but by a committee, aka T39. All the implementations of JavaScript are open source, like V8, JS core, etc. NPM is closed source, with the actual registry being completely closed source and just paid tiers for private packages, run by a company. The JavaScript registry needs to be open-source and governed by a community, open to innovation and run by a committee. Building trust involves convincing respected independent leaders from across the ecosystem.

JSR is open for the reason that JavaScript is controlled, not controlled by a company, by a committee, aka T39. Then all the implementations of JavaScript are open source, like V8, JS core, et cetera. And then NPM is closed source. The only open source part is the CLI, I believe. But the actual registry is completely closed source and just paid tiers for having private packages, et cetera. And it's run by a company. And that does not fit with the rest of the JavaScript system. And so the JavaScript registry needs to be open source and governed by a community. And open to innovation and be run by a committee of some sort.

So who is running this? Well, we have a few people. And to run a project like this, you have to build trust. And a huge part of what it takes was convincing respected independent leaders from across the ecosystem. I mean, you need to have a foundation to convince more people to be able to make this something actually that works out. And as such, we have a few people that join the governance board. And this demonstrates our commitment to being really a community project.

So the people are Evan Yu, the creator of Vue.js and Vite and founder of Void Zero. Then we have Isaac Schluter, the creator of NPM and cofounder of VLT.sh. Then we have James Snell, who is a Node.js member and the principal system engineer at Cloudflare. Then we have Luca Casanato, who is a colleague of mine that works at Deno and also a member of TTC39. And finally, we have Ryan Dahl, who is the creator of Node.js and Deno. And that encompasses our current board members, but in the future, we might get more on the board.

But the board really only does a few things, which are overseeing that GSR moves to a foundation. I'll get into that in a bit. And then setting the general direction of the project. Making decisions on behalf of the project when necessary. So really, this is when there is any conflict of interest or there is a drastic decision change that we want to move to a different provider for our infrastructure, etc. And determining how governance collects in the future. So if we want more people, this has still not really been decided on just because we're currently happy with the five people we have. And then determining how open source contributions to the project are made. Currently, we don't really have a policy. It's more like, yeah, this looks good. I'm gonna merge it. But we don't have any strict rules around how we want to run this project. As in what type of contributions we want to accept, what not. It's really currently just on a case-by-case basis that I decide, yes, let's merge this. Or any other of the maintainers, that is.

So we also have a moderation group. So again, GSR is public and it's a public infrastructure. So like many other public spaces, not NPM for example, but in the case of GSR, it needs maintenance and safety rules. So we have a group of people that handles any kind of human side of things. So reacting with people having issues, there's a name dispute, there is security reports, policy enforcement, stuff like that. It's very moderating, the entire system. And this obviously is quite important. But people usually don't care about it. It's not very thankful job. It's relatively thankless. And part of what it takes to keep the registry running safe and reliably for everyone. So for that we have Oliver Methurst, who is a creator of POP4, which is another JavaScript engine. Then we have Augustin Mori who is a contributor to Node.js and GSR as well. And then we have Dr. slash Blackerslight, contributor to GSR.

These are relatively people that we trust. It's not really about getting people that are popular or famous, but really people that are willing to do the gnarly job of responding to support tickets and having to deal with any kind of problems.

As I was mentioning, we're talking about moving to a foundation. So what is this foundation? Ideally, we want to move to an open foundation where GSR, currently owned by the Dino company, can be managed independently to show openness and community ownership.

An alternative approach could be establishing our own nonprofit foundation, which is faster but comes with legal responsibilities. The process of transition, whether to an open foundation or a nonprofit entity, is ongoing. Recent features for GSR include detailed download metrics and the introduction of a dark mode.

But we'll see what happens and also ECMA seems to have some interest. But overall, it's a slow process. So we'll see what happens.

Now, an alternative would also be that we just have our own foundation. So rather open nonprofit company. That's also an approach we've been thinking of doing. It's a bit less defined and not entirely sure if we're going to do that.

It has its different problems, like you have to take care of legal stuff yourself instead of OpenGS taking care of all the legal shenanigans. So we'll see exactly what we do. But creating our own nonprofit technically is the fastest approach, and not having to wait on processes from these other organizations. But we'll see exactly what's going to happen. It's a slow process overall, regardless of which approach we do.

And we'll try to push this forward. But yeah, it will come as it comes. But it's already being treated as an open thing.

Then let's see some of the recent and upcoming features for JSR. So I mentioned a few of the key features at the beginning. But some additional features that we recently added was relatively detailed download metrics. So when you go to npm, the most you see is the weekly downloads on a relatively tiny bit.

With JSR, you can see actual breakdown of all the versions of how long they have been having downloads. So you can switch between daily, monthly, and weekly. And at one point, we'll also add yearly, but that's currently irrelevant. And then we also have recently added dark mode. I mean, that's just people have been asking for it, so we just did it. It was quite a while. But it's not a key feature, really, but people ask for it, so we give it.

And then we changed a bit of our package archiving infrastructure, because on JSR, you cannot change things, really. You cannot delete existing packages. We cannot have a left-path situation again. So the idea is that it's immutable. So if you publish to JSR, your package is there. We will only take things down in case of legal disputes or any other relatively similar type of situation. Or we are working on it to adding also the capability of being able to yourself being able to delete a package version if it has less than ten downloads and was published like less than two hours ago.

We want to give people the flexibility to delete the packages under certain circumstances. But not always, because, again, left-path, we don't want to repeat. So anything cannot be deleted, but we have archiving. So like on GitHub, you can archive a package, and that will just remove it from the search, will not make it visible. But it's still there. So you can download it. And that's relatively it for the most recent features. And then we have some upcoming features, which is our revamped search. So this goes also from reworking our current search to be a bit more easier to use and a bit nicer.

But also this adds scope level symbol search. So in GSR, every package is under scope, unlike NPM, where that's relatively optional. And currently, you can search for symbols, aka function classes, et cetera, from a package in a package. But there is the use case. For example, we have the add STD scope, which is a standard library scope that provides various functionality. But you don't want to go through every package and find which one has the right functionality. So we're going to add search that will let you search for every function, every class, every interface in that scope.

But then we're going to also one-up that, and we're going to add functionality to search for any function, any class, anything across the entire registry. No matter which scope, which package, you can just search in a global search, and you'll get results. Similar to Go, from what I believe. And then also one more feature we want to work on soon is changelog generation and diff. This sounds quite boring, that we just generate a changelog, as you see on GitHub. But no, this would actually give you a nice diff between previously changed functions.

So let's say version 1.0 and 2.0 have some signature changes. It will display that as, oh, this changed. And you will see a nice diff being able to compare what the changes were, making migrations to new versions a lot easier. And that's pretty much it that we are currently working on and want to land soon. So I guess we can take a really quick peek at JSR. Let me see if I can get this to work. There we go. So we want to go to, oh, God, my laptop is being very slow. There we go. This is the JSR website. Seems relatively boring. There's not much to see. We have a few blog posts here. We have featured packages, which we manually select which packages want to be featured, recently updated, and new packages to JSR.

Then we have basically similar top points that I mentioned earlier. But we can take a look at a popular package. So I can go to at STD. Again as I mentioned just now, it's a standard library scope where we provide various standard functionality. This is maintained by the Dino company. And we can just jump into collection and we'll see some interesting things. It's big enough.

Okay. Well, we have this work with which shows what runtimes is compatible with. This is decided by the maintainers. Not automatically because detecting that automatically is relatively tricky. And then we also have a score. So JSR scores your package because people love gaming stuff. And the scores are based on various different pieces of information like has your do you have documentation on your symbols? Do you have a description for your package? Did you pick any runtime that's compatible with, et cetera, et cetera. And we are going to add more over time.

The goal for the score is not about really oh, this package is better than that, but it's more about making people use good conventions and making better packages for the whole ecosystem. Then we have the weekly metrics as we see this is very similar to npm, but I can click on that and you will see a nice graph for this is on a weekly basis for this package. You can change this to monthly if you want. And okay. That's my laptop is being extremely slow right now. Anyhow.

And one more feature I can quickly show off is not in this package. But we have a list of dependencies. But in addition to a list of dependencies, you can generate we generate for you a dependency graph. So I think assert depends on one package. Okay. That's useless. But we can go that, for example, and you see a list of dependencies, but you can also go to a dependency graph, and it will generate a graph usually. Yes. There we go. Which generates all dependencies for internal files of the package. But also in yellow it highlights packages like external dependencies to a different package. And in red it also will highlight any npm packages. Now I don't have a direct example for that. But yeah. That's that.

And I guess we have one minute left that I can quickly give an overview of the docs generation. So here we have the assert library. It has various symbols. We have a default entry point and we have the assert function. And this is generated this content is generated by the JS doc comments via the JS doc comments and generates type like what it accepts, some documentation, examples, as defined parameters, return types, et cetera. So it gives a full breakdown, and it also shows you on how to use this. So you can run a command to add it or you can select whichever system you want. It will remember it for you. So you can go to pnpm and it shows you how to use it with pnpm, et cetera. And yeah. That's pretty much it for JSAR.

And yeah, we have weekly, biweekly meetings, open meetings, you can join. You can go to the link. There will be a calendar invite. And you can go to JSAR.io to use JSAR. And we also have, well, it's open source, so please contribute. There's a lot of simple fixes that are marked as good first issue. So we will love some contributions to the project. Thank you.

So first, have JSAR supported private packages yet? We currently don't support private packages as of now. It's not difficult for us to support, but it's just yet another feature we want. We have a relatively long issue tracker with a lot of requests of a lot of features, and there's limited manpower. So at one point, it's going to come, but not now.

Well, that's a tricky thing, but the whole point of JSAR is to be a better NPM, or a better alternative to NPM, and we already have seen interest from various maintainers of relatively big packages, like having multiple, like over tens of millions of downloads. And they are interested in moving to JSAR. And the blocker for that is NPM CLI supporting JSAR. So that's something we're going to try to push forward. See that the NPM team is going to allow us to add native support to NPM for JSAR. But yeah.

And they are interested in moving to JSAR. And the blocker for that is NPM CLI supporting JSAR. So that's something we're going to try to push forward. See that the NPM team is going to allow us to add native support to NPM for JSAR. But yeah. Sounds exciting.

Ok, Dominika is asking, is it possible to self-host a JSAR mirror? So yes and no. So self-hosting JSAR is doable. It needs some setup. You currently have to setup like GCP and AWS and all that infrastructure stuff yourself, but it is definitely self-hostable. We want to make this flow a lot easier for people, and we also want to add mirroring to such a way that you can have a JSAR registry instance as a proxy.

Are you taking steps to increase diversity in the governance group or moderator team? We have not done any specific effort in that. Just because we wanted to start off with a team of people that we already know, and people that are, well, well-known by the community. I mean, I hope that most people would know those people on the board. So we will definitely increase the diversity of the team. But right now, we are focusing on just getting things done, and then we'll see to improve this.

That is nice that you are working on them. And the next one, are you taking steps to increase diversity in the governance group or moderator team? We have not done any specific effort in that. Just because we wanted to start off with a team of people that we already know, and people that are, well, well-known by the community. I mean, I hope that most people would know those people on the board. So we will definitely increase the diversity of the team. But right now, we are focusing on just getting things done, and then we'll see to improve this. I mean, we're probably going to improve this also beforehand, but yeah, it's definitely something we'll do. Let's hope so.

Do you perform any virus or harm detection on the packages? Again, another feature that we have on the issue track and that we have not had a chance yet. It's a high priority one, because if you cannot be sure that anything is safe on GSR, then I mean, obviously, that's going to cause issues. So it's definitely something we're going to do. We are thinking about how we can exactly do this. It's not too difficult. It just needs sitting down, like every other feature. We're going to do it. Let's hope you can fix it properly.

Can GSR packages be used in a non-typescript codebase? Yes. So basically, you can depend on GSR packages in any of your Node projects, if you want, and we actually do the translation for you. So we generate JavaScript files and the source maps correctly, and when NPM or PMPM or YARN downloads the package, you will get it transpiled, whereas when you use it with Deno, Deno will just pull the individual files directly. It's slightly more performant, but in the end, you get the same result. Okay.

Yeah, another question with a lot of likes, and replies, actually. Do you have the feeling that JSON5 will ever be supported for Package.JSON, or any other same-format supporting commands? I don't know about Package.JSON. I mean, we have our own configuration file, which is GSR.JSON, which has four fields, which is the package name, the version, the entry points, and the licence, and that's JSON C-compatible. But for Package.JSON, yeah, that's... Ask the NPM team. Okay.

What does the Package.JSON look like of a published package? Still have main model exports fields? Well, I think you just answered that. Yeah, so we have a GSR.JSON that has an exports field where you can specify a string or an object. A string is the default entry point, and else you can do some scenarios with the object as well to make a default entry point or additional entry points that you want. But everything that you want to import from GSR has to be specified in the entry points. So yeah. Okay.

And they ask if there's a quick migration path or maybe a guide. I mean, so one thing with GSR that I forgot to mention is that it's ESM only. So we do not support CJS. And that is for various different reasons, but also because ESM is the future. More packages are moving to ESM and less CJS is being used. So the way forward, or rather, migration path from NPM to GSR should just work with maybe some slight tweaks. If you're using CJS, then you will have to change quite a few things to be using ESM instead. But overall, it should work. If there's any problems, I mean, just open an issue. And like the CLI has... Like we have a GSR CLI that you can use to publish to GSR and it gives you relatively useful error messages. So if that doesn't help, then yeah, open an issue, please. Nice. Then they have a way to go for sure. How do you think to reduce the problem of scope in NPM is maintained from a different person? This could be a security issue. Scope in NPM is maintained? I'm not sure I understand. There's a problem in NPM, I guess. It says scope in NPM is maintained from a different person.

Oh, I see. I think I understand what the problem is. I think what they're asking is about, let's say, I have scope STD, for example, but someone else wants to publish to it as well. I think that's probably it. And if that's not it, I'm sorry, but I'm going to respond to this. If, let's say, someone is name squatting a scope, like, let's say, I, for example, have the Google scope, even though I don't work at Google and it doesn't belong to me, we will transfer it to the Google company. If there is a scope that's actually being used and it is named, like, doesn't belong to the actual person, then we'll still see to move it to the correct owners. So we will have discussions with the current maintainer of it, see why they have that scope, if they have valid enough reason, then we'll talk back with the people that want the scope and go back and forth. But so far, everyone has been just, oh, yeah, this company wants the scope, yeah, we'll just give them to them. They have had not any problem. And also we have reserved the top 500 packages plus a few more and other companies as reserved scopes, so you cannot just create the scopes. You will have to you will get a popup when you try to register those scopes and it will say, please open a ticket. And then we will assign it to you because, for example, we don't want random people to just creating, like, at Discord and then have weird things or like at Google or whatever. So we will be taking care of that. So you cannot just name squat and do things that other people should not be doing. Have sense. I mean, that's that could be a really great bridge.

Any plans for enterprise usage? So as I mentioned earlier, the proxy thing is probably the key thing for enterprise so that you can self-host yourself in your enterprise and have a flow back to the main registry. And I guess private packages kind of fall into enterprise usage as well, to some degree. And yeah, we don't have that yet. But at some point it's not difficult, but again, yeah, we'll get to it. You need time. I mean, again, please contribute. We will love some help. It's nice that they can contribute then.

Are you planning to release a CLI tool too? Yeah, so we have a JSR CLI that you can use via MPX. MPX JSR should just work. And you can use that to publish to a JSR. And that's it, really. You can publish to JSR and that's it.

And you can also download packages with it. Because with NPM currently not fully supporting JSR out of the box, we are doing some trickery using the .npmrc file, which you can specify a registry. This is what usually companies do in the enterprise situations. And basically we are using that functionality to point to the JSR registry as an NPM alternative registry.

Perfect. Can JSR let you see production-only downloads with only bundle minified servers? I'm not sure I fully understand what's being asked here. I mean, production-only downloads. I mean, if you publish packages, it's semi-compatible. So if you do pre-releases, then you can publish that. I mean, whatever you want to publish, you can publish. There is no specific enforcements of what's being published, is it production-ready or not. That is really up to the package maintainer and authors. And you can upload minified stuff if you want to upload minified stuff. We don't recommend it, but you can do it. Get it.

Do you think people prefer new features over sustainability? Did you make any research on this? In what sense sustainability in this scenario? I'm trying to think. I mean, JSR is not expensive to run, let's put it like that. It's relatively sustainable for us currently. It has relatively low expense costs, especially because NPM is relatively old and it has a It's more like NPM has many layers to it and it's built over time. So it has a lot of churn and it's not optimized in some aspects. Whereas JSR is brand new, we thought with these problems that NPM had to solve over the years as key elements that we had to do directly. So we don't have as many problems with that. But also, we are much smaller than NPM, so we don't have as much traffic. So yeah. At least you can fix that and then start doing more features with security.