JSR: The New TypeScript Package Registry (NPM Killer)

the whole package ecosystem in JavaScript. So welcome, Luca. Thank you so much for coming on. Thank you so much for having me. And, also, if you're asking questions of your Node, like, hey. Why did this bug happen? Maybe you want to have a tool like Sentry on your side. Head on over to century.i0forward/syntax.

Sign up, and you'll get 2 months for free.

Yeah.

So JSR is a new JavaScript registry that we're working on built for modern JavaScript, for TypeScript, for any runtime that wants to use it backwards compatible with Node and NPM.

Yeah. Just all around better experience for publishers and packages, for users and packages.

Yeah.

That is a great question. So Npm hasn't really evolved in the past 10 years. Right? It's like, there's been the addition of the files tab, and, like, there's been a little blue TypeScript icon in the top left they added a couple years ago. And other than that, that's kind of been it. Right? And this is not really how we want JavaScript to progress. JavaScript is a very dynamic language.

There's new frameworks popping up all all the time, But in our package management and package registry ecosystem, things haven't really changed over the past 10 years. And I don't think for the better. Right? Wes are still so in it when JavaScript started out, we didn't really have, all these different concepts of of common JS pnpm, ESM and TypeScript and bundled and minified and all these things. Right? You just publish some source code and consumers would then import that source code and do whatever they want with it.

And over time, this has shifted to you write your source code for your package in TypeScript. And then you have to compile it to common Wes and to ESM. And you have to publish Wes files. And you have to have an exports field in your package. JSON that has conditional exports in it. And then you have to, like, have some nice documentation site for it and all these things. Right? And it's it's sort of gone away from being an easy place for you to publish your your tools, to Mhmm. You have to spend a lot of time configuring things before you can get anything usable onto NPM.

And we kind of wanna go get back to where JavaScript started out here to this place where you can just publish your source code. And then, Node understands CSM, Cloud understands CSM, Cloudflare understands CSM. Everyone understands CSS. Do you know understands CSM. So why not just only use CSS? Right? And then TypeScript is the most popular, like, alternative syntax, I guess, for for JavaScript there's right now. Mhmm. I I don't remember what the latest stats are, but there's every month, there's a new stat about how many new projects using TypeScript versus JavaScript, and that number is just going up. Right? And it's above 50%.

Realistically, like, if you're writing a new project, you're writing it in TypeScript.

So why shouldn't our registry support TypeScript out of the box? So that's exactly what JSR does. JSR can publish your TypeScript to it, and then we figure out how to get it to everybody who is going to for your package.

And if that means transferring to JavaScript and ESM ID. Wes files, we'll do that behind the scenes, but you have to think about it. And if it's if you're putting from Deno, that just supports TypeScript, that'll work just fine. If you're importing from BUN, which supports TypeScript, that'll work just fine without any transpilation.

Wow. So to be clear, is this it is ESM only. Is that, explicit? Yes.

Cool. And does that enable you to do some of the cooler things that you all are doing, or is it just a detail?

No. Absolutely. Wes is is much better to statically analyze than common JS.

And we do a lot of static analysis on the source code we upload because we provide things like documentation generation and certain ESLint and things that are just built into the red to the registry.

And we wouldn't be able to do those if we had to support, CommonJS in in addition to ESM.

And, also, it it makes it very simple. Right? You don't have to make a choice when you're writing a package. You're writing Wes.

Yeah. Thank you for that.

That is absolutely correct.

I I I'm here today with my JSR hat on. Well, actually, it's a t c 59 hat, but in in imagine me with the JSR hat on. Right? I am not here in in a Deno capacity in that sense.

This is a registry for absolutely everyone who uses JavaScript and TypeScript. And Wes, we really, really want to hammer this point down. Like it is this package registry is not a Deno registry. This is the registry that you could use if you're using a node modules folder, if you're using Cloudflare Workers, if you're using BUN, if you're using Vite, if you're using Next. Js on Purcell, if you're using AWS Lambda does not matter. Right? JSR will point with it.

And if you write your packages only for node, that's fine. Publish them to JSR anyway. Right? You will get a bunch of benefits that you get that you do not get from NPM.

It is not a junior registry. It is a everyone registry. There's a JavaScript registry. That's where the name comes from. JSR, JavaScript

registry. And in that regard, how how do you go about installing things from this registry instead of just Npm install? Yes. Great question.

Yeah. That's a fantastic question. And this depends on how you want to install your JSR packages. So, like, you know, maybe in Deno, Deno installs NPM packages using Npm colon specifiers. And similarly, you can install JSR packages with JSR colon specifiers.

But in node, everybody is using Npm or PNPM or Yarn, like package managers.

And for those, you can just install JSR packages with Npm or Pnpm or Yarn or bund or whatever you use to install right now. The only thing that you have to do is create an NPM RC file, either in your home directory or in your project directory, which will tell NPM that it's importing packages from JSR.

And after that, you can just run NPMI.

And everything will just work. They will be cooked into your modules folder.

TypeScript will work. Everything will just work. Beep will work.

Nothing else JS set up.

Yeah. So the the way it works is that, if you're importing from NPM, all packages on JSR exist in sort of a virtual at JSR scope on NPM.

So and and there's no packages on NPM that are published into the at JSR Scott, so there's never a conflict here. So if you wanna import, I don't know, the standard library, FS package, you could do at Wes slash STD underscore FS to import it in in NPM.

And, yeah, this NPM RC file just sets up NPM to download anything in the Wes scope from GSR, and everything else gets reported from NPM. So these these 2 can really completely coexist.

All the NPM all the existing NPM tooling just works, complete harmony.

Yeah.

I absolutely, we think this could be done. So this could be usually achieved through loaders. So like all the all the big tools like Veed and and Rollup, and they all have this loader support Node node has a 2 now.

I think it's dash dash imports. It's the flag you use for it.

And with that, you can implement support for JCR colon specifiers.

We haven't done this yet because we want to first give the broadest possible compatibility and the broadest possible compatibility is with through our node modules compat. But over time, we hope that the ecosystem will build these loaders. And we'll we'll publish docs for this. We'll publish docs for how to build these loaders. It's actually incredibly simple because JSR uses, HTTP specifiers under the hood. It like, all the files are loaded from HTTP, which is the same way that browsers work. It's it's well defined behavior.

And there's, like, a very small layer on top of HTTP that, you need to implement to sort of resolve the j s r colon whatever package to, specify. Right? And we'll have documentation for this, and and we'll we'll help people implement this. And over time, we hope that more and more tools will like, we call this native JSR support. Wes support JSR natively in this way. Cool. I like that a lot because

Yep. That's exactly right. Yeah. It does seem like there's a lot of least resistant. You know? There there's no resistance to get up and running with this tool, which I think is precisely what you need if you want people to replace their their package manager. Right? Well, I saw on Twitter a lot when this was announced or people started talking about it. Why can't we just fix

So, you know, if if GitHub or Microsoft or whoever is actually responsible for NPM nowadays, which is kind of difficult to tell, with open source all of NPM and say, hey, Here's where you submit PRIs. Let's fix things. Then absolutely we could do this, but they don't. Right? It's it's a closed source product, which is, I don't know, still for profit. I'm I'm not quite sure what their business model JS. To be completely honest, they have this, like, monetization feature in it with private registries.

This is absolutely not how we want to operate JSR. JSR is going to be a a community resource. JSR will be open source.

All of JSR will be open source. All the back end, the website, all tooling surrounding it, the docs, everything will be open source.

I'm I'm here as a member of the general company right now, but JSR will have a moderation team that will be based not just of contributors of Deno, but of the whole JavaScript ecosystem.

Want this to be something that is really driven by JavaScript, by the JavaScript community, not by any individual company.

And, JSTAR is built to be very, very cheap to operate, which I think is very important because we don't want to monetize JSTAR in any way.

Initially, did you Node company will will pay for the hosting of of JSR? We we expect to be able to do this for a long time. It'll it'll be very cheap to operate.

But, yeah, if other companies want to engage here, this is something where we we'd be totally happy to, like, have other people chip in. Right? But I I really wanna drive from the point here. This is not a Deno registry. This is a all of JavaScript registry, and that means that this needs to be managed by the not by a single company. It needs to be paid for by the JavaScript ecosystem, not by a single company.

And and this is really what we're aiming to do here with JSR.

That's so good to to hear that. It's not it's not the Deno registry, which I think that Wes,

I don't know if you have any thoughts on that as well. Yeah. No. I I I do. I rant. I I think what you're saying is absolutely correct. Right? And I think there's, like, parallels that could be drawn here to, like, serverless compute infrastructure. There was a time when to host something, you had to sort of spin up a server somewhere, deal with, like, APT to install Nginx and, like, manage let's TypeScript certificates and whatever. Right? And now you write some JavaScript in, like, cloud cloud workers.com and click on deploy, and it's live in like 3 50 regions and what, 2 seconds.

Or you do the same when you deploy or on Vercel or whatever. Right.

And if you and if you, like, make this so easy that people can come up with really cool things that maybe they would have not spent time on doing previously because they didn't want to set up the Terraform configuration for this or the Amazon CDK, whatever. Right? Like, this is this is you you don't want to be dealing with bulletproof. You want to be writing the code that you actually want to write. That's why we're developers. We're not developers to, like, configure stuff. Right? That's Yeah. Foster line would Scott into that. Somebody else let let somebody else do that.

And JSAR is really, yeah, trying to do that.

Give you a way to just write your code, publish your code, and then the registry will deal with the configuration. It will deal with hosting it quickly all over the world. It'll deal with serving it in to all the different users that want to use it and, like, generating documentation for it and all what whatever. Right? All those things.

Yeah. Let's let's, dive into some of those features then, like auto the auto documentation like you just men mentioned. Can you can you go deep on that?

Yeah. Absolutely. So because you're publishing TypeScript source code, we have a lot more information that we can pull directly out of your source code as compared to, like, transpiled JavaScript or d.test Wes.

Because we can look at your source code and see that you have a function here that you're exporting, which takes a string argument and, like an options bag and returns a promise.

And we can render that, with a nice sidebar that says, like, here's all the functions this module exports. Here's what they take JS what they return. You have some JS doc on that. We'll render that with markdown. You have some examples that will syntax highlight for you. Right? And this this way, you're gonna have a really easy way for you to go to a package, press the symbols button at the top, and this gives you all of the things that are exported by this package. It gives you a really quick, easy overview of everything you could do with this package. You don't have to read through long pros, anything. Right? You you you can just see that, and search there where you can search through symbols. You can search through the JS doc. You can search through symbol names, the parameters, the return types.

If there's a symbol in there that you don't recognize, you click on it. It takes you to the definition.

If you want to see the source code, you click on the go to source button and it takes you to the source code. And this is the actual source code. Right? This is not like some transpiled minified JavaScript. No. No. No. This is the actual source code.

It's it's pretty nifty.

Yeah. I've gotten so used to this flow after working in Rust of using Docs RS to to just understand more about the libraries instead of going to, you know, quick start documentation.

I'm just reading the source, reading the inputs and outputs, reading the comments. So, yeah, this is, definitely something that I'm happy to see.

Yeah. Yeah.

Node. Absolutely. And and, like, these docs, we we try to integrate them with, like, all kinds of resources. Like, you can click on the the package that you published, for example, may be able to see like, you have a weight function that takes a number and returns a promise. You hit if you click on promise, it sends you to the MDN page for promises, because hey. Why not? Right? Like, these are this this is the kind of thing that, we just wanna make it super easy for you to get to what you're looking for.

Wow. Yeah. That's awesome. And, in addition to that, I mean, there's the auto types thing so that you don't have to generate the d.ts files. Right? Is that just, you know, be working similarly to how you're doing the automatic docs? Is that the scoop?

Yeah. So, the the way that works is that for tools that support importing TypeScript natively. So for example, Deno, we'll just give those tools the TypeScript files directly.

And for the tools that don't, what we'll do is we'll take the TypeScript and strip out all the types. So we're turning it back into plain JavaScript.

And then we also submit some d. Wes files, but we also make sure to set up all the source maps in such a way that when you encounter an error and you you get a stack trace, it actually shows the original source rather than the JavaScript.

And then we put that into, like, an empty interval, and that's what you get into your node modules folder for Node, for example. Right? Because node doesn't support executing TypeScript natively.

If node Wes ever to support using TypeScript natively, then, it could also just consume the TypeScript directly. But, yeah, for the tools that don't, we we do the translation for you. You don't have to think about it. It just happens to the background, and you Yeah. Don't really have to think about it at all. Yeah. I love that. So another question we had commonly was like, well, can't you just put TypeScript files on NPM? Like,

Yeah.

Sure. You can try.

But I think it like, nobody's done this over the past 10 years because I don't think it's like a very viable approach. Right? It means that now this is essentially the same problem as the loaders where instead of it just being supported in all the tools natively, all the tools that you want to consume that package in now need to have some additional tooling set up.

And this really, really limits how far you can distribute your packages.

Because if you're gonna have some like internal team at Google that has a predetermined build setup that maybe understands node modules, want to try to import your package, they can't because they cannot add a new loader to their node builder or or whatever. Right? Yeah. So you Node, you don't really want to do this. You want to have for the tools that do not natively support the system, give them a way to easily downgrade.

And with NPM, if NPM natively supported, like looking at the tarball and and transpiling TypeScript to JavaScript, this could be a viable approach, but Npm doesn't. And, I don't see NPM doing it anytime soon. Right? Like the the last big feature they launched Wes, I think, package provenance, which,

does anybody even know what that is? Yeah. Yeah. Who's yeah. So big information. What is that? Package

Package fragments. It's like a it's a security feature to be able to ensure that a package was actually published by the person who claimed is publishing the package. But, yeah, this JS exactly case in point. Right? Like, the the last big feature they launched, you don't even know what it is. So Yeah. No way.

from the Internet and And and then randomly execute, like, a pack post install step on it too. Like, you can't even see what it's gonna do.

to to do that for security as well? So JSR is not doing any sort of scanning the same way that, like, Snicker or Scott warp. Yeah. We expect that these tools will be able to data. We integrate with JSR if they want to.

We will have support for features like package provenance, even though maybe it's not such a super well known feature, but it's it's useful for sort of supply chain security, to be able to ensure that the person that is publishing a package, is actually the is actually who they say they are. We also all of our files are obviously hashed in in such a way that, like, you can ensure that the files that are installed to disk are actually as a policy that the registry is attending to serve.

You have we've put a lot of effort into making automatic publishing, or sorry, tokenless publishing possible, which is sort of down the same, train of thought as NPM's requirement for 2FA recently. I don't know if you saw this, but, like, NPM has required, I think, for the top 1,000 package authors that they enable 2FA.

And in JSR, all packages you publish from your local machine must go through a sort of interactive authorization flow in the browser. So when you when you type in, you know, publish or or JSR publish, it prints out a link, you click on the link, and then it shows you, here's what's gonna happen. Do you wanna authorize this or not? You sign in with your GitHub in in the browser. You you click okay.

And then it goes and publishes. And this is sort of 2FA. And and we want to we're we're doing the same thing for publishing from GitHub actions, where you do not have to set up any secrets. There's no, like, access tokens you can leak, but instead, we use our built in security mechanisms inside of GitHub actions.

For those who are familiar, OIDC tokens, that let you publish directly from from GitHub Actions without having set up a new token. So there's nothing to leak there. There's no way for you to accidentally expose your token to a bad actor that may then use them to publish anything like that. And all the tokens we use are very short lived.

Like, we we've we've thought about this, to to make sure that it's difficult for people to publish maliciously and to sort of avoid a lot of the pitfalls that it came has, or has had in the past, and and we're trying to not repeat those mistakes.

So you can actually set it up however you want. It's it's just a step inside of your GitHub workflow file like, GitHub actions workflow file.

So you can set it up to publish on tag, or you could set it up to publish every commit.

The way it works by default is that it looks at the version inside of your, you know, JSON or JSR JSON file.

And if the version is already published, it'll do nothing. It'll just skip over the step. And if it's not already published, it'll go publish it. So, yeah, the the way you can set it up, the way we've set it up in, for example, our standards library is that, when you merge something to the main branch with a new version for any of the packages, it'll just go publish that package, and you don't have to tag. This is great for mono equals.

But we've also heard feedback that for people that would just like to be able to publish on tag. So we'll have a flag for that. We can just specify the version directly in the, you know, publish command or a JSR publish command.

No. You actually don't have to switch. This is a feature that you haven't seen yet because we haven't released it yet, but you will be able to publish with just a package JSON file. So if you have a package JSON file that has a name and a version in it, you'll be able to run JSA or publish, and it'll just pick that up as the file.

And it'll, like, understand the, like, files section of the package JSON and the dependency section and all of that out of the box.

Cool. I I know that, you know, when Deno was first announced, the big thing was installing from URLs only.

Mhmm. And, you know, then became the whole DEPS file thing, which was essentially just a package file, you know, of imports.

Is is Deno vision still to use imports that way? Or I know this is not Dino's package registry, but do you do you all see this as being the way forward for Dino?

Yeah. So the way that the the thing that we've settled on in the recent in the last couple of years is the import map spec, which is supported in browsers and allows you to do something very similar to package adjacent dependencies, but in a standard way where you can, like, set a certain pair specifier to map to an Pnpm package, an HTTP package, a JSR package, a local file, a data file, what whatever you want. Right? And this is we've added support for this natively inside the DenoJSON file. So you can create a DenoJSON that has an import section, the import map inside of it. And this is what we recommend people to use. And this will work totally fine with the JSR.

And when you're publishing a package that uses an input map, this will also just work. We do some trickery behind the scenes to sort of take all of the beer specifiers inside of your pnpm map and just inline them into your source code so that during installation or or the consumers of your code don't need to actually then know about your bookmark, but rather, like, all of the configuration and dependencies are described in the source code, which is really nice. And under the hood in Deno, Wes.

So this is sort of a you don't see it, but actually they should be specifiers, which is kind of similar to how NPM does it because Npm Npm install is also just downloading a bunch of tarballs from HTTP. Right? It's it's really nothing other than slightly more complicated HTTP URL. And this this just gives them a nice facade, a nice easy to use friendly face.

Yeah.

So JSX and TSX files will be published publishable, as source. So you don't have to transpile them before publishing them.

Just how TypeScript works. Right? And if you're then consuming them from Node, they'll be transpiled.

Just how, TypeScript files are transpiled to JavaScript. JSX files will be transpiled to JavaScript.

For other files like Wasm files, we're really betting on the Wasm imports proposals that are going through TC39 and and what way you can the WebAssembly community group right now that would just allow you to import WebAssembly files through regular JavaScript imports.

And then CSS, something similar will not quite settled exactly how this will work, but likely you will be able to just expose some CSS files from your package.

And then same goes for, like, any other type format of file. Right? Vercel file or or view file. Or

which surprised me that that was a standard. But, hopefully, we'll just start seeing more of those in the future as well. Yeah. Like, in in Deno, we we have support for JSON right now, and we're working actively on support for WebAssembly. We're hoping to ship that maybe, I don't know, a couple months.

Node has had a implementation of WebAssembly imports for a while now behind a flag. So, yeah, hope hopefully, by, like, middle of the year, WebAssembly imports, they're just, like, a thing that you can use.

Yeah.

Solatype. So this is needs to needs pnpm explanation for those not initiated. Yeah. TypeScript is a very dynamic typing system in the sense that like, you can be very, very loosey goosey about how you add types to your functions or constants or whatever.

Namely, you can not specify any types and just have TypeScript infer everything. And what this means is that if you have a function body that returns a string, TypeScript will you don't have to like add a string return type to your function, but instead TypeScript just can infer that the function returns strings because you have a return statement that returns a string literal. But this poses some problems, namely that inference is generally very slow.

And TypeScript has acknowledged this, the TypeScript team knows about this.

And there's a new mode that they're introducing called isolated declarations that it's sort of like strict mode in that it adds some more rules around what you have to do with TypeScript.

Namely, you have to add explicit return types to all of your exported functions.

And what this does is it saves a lot of time in this inference because TypeScript doesn't then have to do inference if you already explicitly specified return type on a function, for example.

And what Json does is during publishing, it really, really nudges you to to not use any of these slow types. And slow types, we just it's just a nicer name for, func types that need to be inferred and are thus slow, slow types.

So when you publish them to JSR and you don't have a specific return type specified, we'll nudge you to add an explicit return type. You can skip this if you really want to, but if you keep it, this will make the documentation regenerate nicer. It'll make the d dot t s files that we generate nicer.

Yeah. It's it's sort of just we're we're early adopter of this TypeScript of this new isolated declarations TypeScript feature that'll be shipping probably in TypeScript 5.5.

Oh, okay. Cool.

You know, I if you'd asked me 3 years ago, I may have said yes. And then after seeing like how slow the progress has been on, on, on Rust based type trackers, I kinda don't think so.

I think that TypeScript will do a lot more to improve performance here soon. I think isolated declarations sort of the first step in a very major push for TypeScript to be able to paralyze more of their type checking, which should hopefully speed up type checking, especially on very large projects.

The the people that are pushing isolated declarations are Microsoft, Google, and Bloomberg, companies that have very, very large code Bos with TypeScript in their companies.

And, yeah, they're running into sort of bottlenecks in TypeScript here and now need to have a more aggressive fix for this. And isolated declarations, I think, is something that is going to at the cost of of some convenience, you have to explicitly specify more types going to significantly improve the the the problem here in in the next couple

months, maybe years. Oh, that's exciting. So maybe that's really the solution. Instead of rewriting the the whole darn thing in Rust, just make the one that we got faster. So hey. Yeah. That's not an it's not a a bad solution.

Yeah.

If if we were to go down a path where we like very explicitly specify the meaning of all the types, I think it would.

Right now it's not really looking like that's going to happen, although things can always change. Right? Like decorators change many, many times over 8 years.

Yeah. Never say never.

But, probably right Node, it's looking more like we're reserving some syntax space in JavaScript for you to put types. And what exactly those types look like is up to the tool that's going to be interpreting them. Oh, interesting.

This is, like, the the Python way of doing things. I don't know if you've used types in Python, but, they Scott of just I have not.

Syntax space or the they're sort of, like, comments, but you can reflect them at runtime, and they don't really have a a semantic meaning

Yeah. Interesting. Makes sense. Probably. But, again, we're we're very, very least. Right? Stage 1. Yeah. Things can still change many, many times before

anything shifts. So we'll see. I and and, like, the tie I know there is no time line for that, but, like, do you see that taking 5 years or 2 years? You know?

That's I don't really know, to be honest. Like, it's it's always very difficult to tell. Sometimes proposals that you think are very quick take a very long time just because you find out it's it's difficult.

And some things that seem very difficult initially go very fast. And this is one of those cases where the proposal itself is very, very large in the sense that it adds a new a Scott of new syntax. And adding syntax is always kind of risky because you need to ensure that none of the syntax syntax, that conflate the existing syntax and also that it doesn't block addition of new syntax in the future.

So there there's a lot of auditing that has to go on there by many people to make sure that this is actually implementable.

If to decide, like, it's Wes not even sure yet whether we want this to be just reserve comment space or whether we want to define the the specific syntax. So still many open questions. I don't think it'll happen at least for another 2 Yarn. But, yeah, I don't know. Yeah. Maybe it'll take 10. Maybe it'll take 1. Who knows? Yeah.

it's gonna you're it's gonna be trouble. You gotta sit with it, yeah, forever.

Yeah. I think I'd probably, like, work out the enums.

We to do enums are sort of a a a feature that does just transpile away, but rather, it turns into something at runtime, which is kind of strange. It's not how the service are. Yeah. It probably would require explicit return types on all functions because we could have much faster type checking if they did. Interesting.

And I think I would ban declare global or at least move it, do it in such a way that, like, you have to have 1 file that you put all your declared globals in. Because that's another one of those cases where if we didn't have to declare global, TypeScript could be much faster.

global types in any file with that type of thing? Yeah. Exactly. And and that means that, like, you can't really, like, parallelize all of your type checking because by the time you get to some file very deep in the tree, you may have to, like, type check differently somewhere at the top of the tree because you've changed the fetch types. Right? Yeah. And interfaces

Yeah. If you if you look at our, like, slow types documentation, it's essentially the list of all the things that make TypeScript slow. So, yeah, like, declare global and module augmentation and export equals and yeah. I don't know. All these fun things.

So the the good thing about TypeScript is that modular decorators, I can talk about those in a second.

Yeah, the TypeScript emit is stable. So for any given version of TypeScript, if you take the TypeScript source code and give it to any of the sort of tools that can strip out the types, they're gonna give you the same JavaScript.

And if they don't give you the same JavaScript, it's a bug in that tool. But like, what what I'm trying to say is over time, TypeScript does not change the meaning of types in in such a way that, like, tools that emit TypeScript or emit JavaScript from TypeScript would have to change their output. And because JSR does never never actually does type checking, but only ever does emitting of d.ts files and emitting of JavaScript files, which is stable and it's like well defined behavior. Right? We don't have to worry about this backwards compatibility issue.

Backwards compatibility. This this only matters if you're checking, for example, the actual body of a function, which you're never going to check the body of a function of your library that you're importing. Right? You're you only care about the return type and the argument types of the function from the library, the Scott of top level interface of that module and not the actual implementation details.

So, yeah, it's not really a problem for us.

And I think it it like, the TypeScript has the stance that they don't break the emit and they don't

break d dot test files. Wow. I think that you know what? One thing that this conversation to me has been very illuminating is just I I like, Wes is posting some in our in our show notes some screenshots of when he tweeted about this, a lot of people responding why.

And this conversation answers that why question for me in so many ways that I feel I went from, you know, okay. It's a new package registry to, this this has solved so many issues that we have. And and so many people's complaints about the the CJS ecosystem, so many complaints about the TypeScript ecosystem.

I think this is just a great, great step forward, and I'm I'm pretty stoked that this exists. So, man, great great work everybody who's been putting in time on this. Wow.

Thank you so much. Yeah. It means a lot.

And we're just just getting started here. This is the initial set of features, but this will be open source. And you know what happens to open source features or to open source projects. They Yeah. Get better over time. Oh, yeah. Right. They're they're super effective. Everybody's

just chipping in all the time. Yeah. Yeah.

Yeah.

So this is a this is a really good question.

And the the completely honest answer is we don't really know exactly what it's going to look like yet because, we can only really figure out what exactly it's going to look like after people start using it, after we sort of know what the reception to this is.

Initially, we were projecting that we'll be able to fund this for a very long time. Like, we're hosting this on on very commodity infrastructure, that is incredibly cheap to operate.

That there's it's everything is immutable in such a way that it's very, very highly cacheable.

It it'll be very cheap for us to operate.

Beyond this, like, there's there's ways we can do this. Right? Like, there's there's ways we could set up a foundation, that has members from many companies and those member those member companies pay membership dues.

There's ways where we could set up a GitHub Sponsors thing where individual people contribute. Right? We're not completely sure about that yet.

What we're trying to do first is is launch this, see what the reception JS. And, like, did you know company JS well funded? And we have revenue sources. And we're totally happy to, to pay for JSR. This is like a community effort that, yeah, we think will really benefit JavaScript and sort of pushes our mission of making Vercel side JavaScript accessible forward in in a very major way. So, yeah, we're we're happy to pay for this for the moment. And then, yeah, we'll see where this goes in in a Yarn, in 2 years, in 3 years.

Yeah. Yeah. I'm sure we could figure it out. It's gonna be ads and install. Right? That's what you're gonna do. So

So Wes what see, this is, like, why we wanna have, a community moderation team. We we we want to make sure that stuff like this cannot be done by any single Sanity, that there there's oversight between, like, across the whole ecosystem.

And we don't think that like, obviously, I trust that the Deno company is not going to do anything bad. I am part of the Deno company. But, yeah, it's better to be, like, set up in such a way that you prevent this in the 1st place through Yeah. Scott of organizational policies. Right? And, yeah, we'll we'll be announcing more about how we exactly, want to set up this this community, moderator program as as we get closer to launching JSR.

No. No. No. I the thing I already take it back. So Okay. Good.

Oh my god. What Wes what we did is, we we set up a system where the top I forget how many it is, packages and scopes from from NPM. We have sort of preregistered these. Well, they're not really preregistered. They're sort of in a, state where you as an individual cannot register them without emailing us first, and then we will verify that you are actually Stripe. And if you're actually Stripe, you get your Stripe thing. And if you're not, then, you Node, and this obviously, if if somebody tries to register Wes, then they probably can, unless you've already registered that. I don't know.

Yeah. Already got it. You're Scott, like, a top 1,000. But, yeah, I think this will be fine.

The the way the way Wes like, we don't have these top level packages to prevent, you know, people from squatting very aggressively, and and we have some limits in place that initially allow you to only register 3 different scopes. So you can't make just register all of all the scopes.

High hindsight is always 80 or whatever

Yeah. Do you want some,

So these are not all confirmed to to be there for the launch, but, we we want to work on package scoring, which I think could be a whole episode all on its own. But, yeah, we wanna automatically assign scores to packages based on certain factors, like whether you have documentation, whether you have a read me, whether you have a license, whether your code is formatted, like, sort of Sanity, like factors indicating quality, whether the dependencies we import are up to date. We also don't have a downloads page because we don't really think downloads are very relevant. We're gonna have, like, a popularity indicator maybe that shows you how relatively popular packages. Like, if it's in the top 1% or, I don't know, in the bottom 99, but one could be absolute numbers.

Change logs, probably Wes wanna integrate change logs natively at some point. Yes. And we have docs. Right? We have docs for every Vercel. So automatically generate change logs based on the differences in your symbols.

that's genius. Yeah. We we have many, many possibilities here, and I think we we have sort of an edge here because publishing source code gives us a lot of these, static analyzability things like the quality scoring and and the documentation generation. And I'm sure we'll come up with other things, that'll, yeah, be able to provide a lot of value to to users. Actually, one thing we did mention is, like, we have, compatibility indicators for different run times. You can, like, market packages compatible with Node or compatible with Cloudflare Workers or Athena.

Yeah. Yeah. Wes we definitely wanna do this. We wanna do it in in a way that doesn't necessarily incentivize old packages in the same way that NPM does.

For example, like, express I I think Fastify, for example, is better in express than than express in, like, pretty much every way. And yet just due to the age, it's ranked lower, in NPM search and in Google, whatever. Right? And we want to have our our scoring take things like this into account. Take into account that maybe packages that are published with modern features and, like, based on what our protocols and have documentation and have been updated in the last 3 years, maybe they should be pushed more than packages that haven't be been updated at all in the last 3 years warp that have 10 new issues every day or whatever. Yeah.

before.

Sick. Well, Luca, this has been incredible. I, I'm really buying the hype. I I think it's pretty amazing.

And, now is the part of the show where we get into sick picks and shameless plugs.

A sick pick is just something that you like right now. Could be anything.

Wes and I have sick picked podcasts, YouTube channels, kitchen utensils, pizza cutters, anything you would like. And then a shameless plug is just anything you would like to plug.

Yeah. That's difficult. I've been playing around with Hono a lot recently, and Hono JS really awesome.

I feel like if anybody Node new right? New HTTP servers and JavaScript and, you know, or Cloud workers or I've introduced

It is hono. And, Wes, you know what? Because you keep saying hono, it's Hanno in my brain now permanently, and I always Google it with an a. And then I'm like, oh, no. It's Hanno. And then I go back I've never once pronounced anything correct on this entire podcast, so don't take anything out.

Yep.

Yeah. Find me on Twitter.

I don't remember what handle is. I think it's let me look it up real quick.

Terrible at shameless plugs. You could tell.

LCAS dev, l c a s d v.

And JSR IO. Yeah. Check out JSR. I don't know when this episode will launch, but maybe the wait list will be gone at that point. If not, sign up to the wait ESLint, and

Later.