JSR: The New TypeScript Package Registry (NPM Killer)

Hey, everybody. Welcome to Syntax. Today, we're talking about JSR.

Is it the new NPM? Is it a new package registry? Pretty excited to talk about it. A lot of opinions flying on what it is. So, we have, Lucas Sanity on today, who is a software engineer at Deno. Deno JS the folks behind JSR, and a member of TC 39. So obviously knows a lot about JavaScript and a lot has a lot of thoughts and and whatnot behind

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.

You wanna give us a a quick rundown of I know I I I gave a little intro, but, give us a little bit more info.

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's awesome. And we're gonna go into all of the the benefits of it, but I think what most people are are tuning ESLint to hear is, even since I posted it for the 1st time, is why why do we need another package registry? Isn't NPM fine? Is this a replacement for? A lot of people seem to think that it was, like, a a Pnpm alternative, and, I just wanna, like, start off first clarifying what it is and and where it lives within the ecosystem, and then we'll we'll get into, I guess, a lot more of the benefits. So, like, let's start there.

What's wrong with NPM? Why why do we need a new registry?

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.

We had, Mark Erickson on the podcast, and he maintains Redux as well as a couple packages around there. And, like, he he went deep, and I I had a whole talk with him on the podcast as well as at a conference about just, like, like, he's a smart guy, and he could not figure out how to get this thing to ship to absolutely everyone. And he just had to go nuclear and and figure it all out.

It's really, really tricky to do that type of thing. And and then you see other people like, Sundre Soeras, who has a 1000000 modules. He just kinda ripped the Band Aid off and pnpm, ESM only. And, also, he's probably responsible for a lot of people going all in on on ESM or sorry. Not even going all in. Like, you can still use common JS packages, but, we need to sort of move past that. So I'm I'm kinda happy to hear about that type of thing. So, I just wanna, like, talk about, like, what it is really quickly to to a bunch of people. And I think the first one, and I think you've done a good job just not saying, do you know right off the bat, which is this is not a Deno only thing. This is going to be a package registry for anybody who consumes JavaScript. Right?

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.

So that's that's the kinda thing that we need to drive home here is that JSR, you can still use with NPM.

You can still get the NPM packages that are not available on JSR yet. Yeah. However, like, I'm assuming the way that it works is that it would just proxies through JSR. And if JSR doesn't have it, it'll, proxy it over to to the NPM registry. Right? Like, at a high level?

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.

That NPM specifier thing. So if you you're trying to imagine it right now, it's if you wanna import something from JSR or NPM, you say import whatever from, and then you you type j s r colon and the name of the the actual package. And in in Deno, I love this because I don't have to npm install something. I simply just type npm ESLint, the name of the package, and it goes off and and fetches it for me, which is is really nifty.

I really wish, like, Node would have that itself. And I'm I'm curious. Do you think that will ever be possible? Because, like, node itself has implemented node colon for for node internals.

Will we eventually get that in, or or can that be done with, like, some sort of hack?

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

I like that the approach that you're taking is not yeah, it works with Vite, but you gotta install this via plug in and ESLint your config and change it. Like, that's not the case. JS it works with Vite right now by by being able to work via NPM. Right? And eventually, hopefully, Vite will say, yeah. Let's add let's add JSR support into it. So it just just works natively. There's not a plug in that needs to happen.

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

NPM? Why do we have to have something Why can't you put your time into fixing NPM? It's a great question.

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,

some of what we heard, right, or or some of what people wanted to hear or did you. You know? I love this because, I think some of the pushback you get from people is like, I just npm install, and I get everything that I want. I don't care about the size of my node modules folder. That's one of the benefits of this JS you're not downloading. Like, we did a whole show of why is why is Node modules so big, and it comes down to it's a lot of text. You know? Like, text is surprisingly big. Right? And I think people aren't realizing is the people who publish these modules, it's really difficult for them to do. And when you make things easier, people make cooler stuff. Case in point, totally outside of the JavaScript registry, you look at a tool we used on Mac CSS, Alfred, for a long time. There Wes some pretty cool plug ins for Alfred. Raycast comes along, makes it authoring and publishing extensions for Raycast super easy and boom. There's, like, a 1000 times more and way better plug ins for actual Raycast. So there's lots of stuff I haven't published because I just don't wanna get into it. It's just too much. I want I author in TypeScript.

I would love to simply just take the TypeScript file that I wrote and publish that sucker to the Internet and for somebody to be able to consume it. But that's that's not the way it works. There's a whole bundling thing. You gotta make sure your exports are all properly lined up. You gotta think about common JS and Wes, and it's just just a huge pain in the butt. And I think that, like, of course, if we have a new registry like JSR, there's gonna be a lot of bumps down the road. I think it's going to be really tricky. But I think long term, this is going to be a really exciting thing and a really good thing for the Sanity. And just just seeing what happened when NPM came on board and how we use it now. I Npm installed home assistant stuff. No problem.

I think that this might be the the next evolution of that. So

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. The doc the docs are amazing. Like so I got access to it. I did not. And Oh. Oh, we should So sorry. Sorry. I should I should've sent I should've sent some emails there. But Just joking. Immediately, I went and published, one of my packages, and I I wrote all the docs in in or sorry. I wrote it in TypeScript, and then I exported a couple TypeScript then I also wrote some JS doc on top of it to provide some examples.

And then boom. Like, all the docs. It, obviously, is a small library, but all the docs are just automatically generated right out of that. You don't have to make sure all the docs are not updated. Or Nice. It's just so such a smooth process to to do it that way.

And rather than have to generate some d.ts files and put them on at types and npm install them. That's such a pain to have to do. I'd rather just require the TypeScript file. We'll be able to look at the docs. And Node to mention the stack traces get so much better when you're simply just importing the author TypeScript rather than some crazy minified bundled ship version. You gotta go spelunking in node modules to figure out what went wrong.

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,

like, can't NPM? Just you can ship any files you want. People put movies on NPM. You know? Can't so why can't NPM just do that with TypeScript, and then you you ingest the TypeScript with a a build tool if you're using Node?

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

fragments?

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.

Yeah. It's it's a bit of a bummer, really. Like, they I I know they had laid off a a good chunk of their team, and and we had Darcy, on from, Volt, which is a similar ish thing, to to JSR. He's kinda gunning for the the same area, and he worked at Npm for a while, and he said, like, yeah, man. We had we had the code tab in beta for, like, 3 years before that thing could go live, and not being able to see the code that you're npm installing is wild. Like, yeah, I'm just gonna download this random code

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.

Well, you that that's my next question is, Darcy was talking about a big part of Vault was, being able to scan dependencies, and then we also had Faraz from socket on, and his whole company is is is doing a fantastic job at scanning every line of code that makes it an Npm and detecting, the rogue ones, which is pretty interesting. So does JSR have any plans

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.

The the GitHub action integration is is pretty neat. Does that publish when you merge something into a branch on, like, every single commit, or does it only go on when you tag a a release on GitHub?

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.

Mhmm. I like that. How many times have you, like, had a bug fixed 6 months ago, but they haven't published a new Vercel, you know, and then some white knight comes along and publishes their own Vercel. You have to go switch out your dependencies.

Yeah.

The the config file is a j s r dot JSON or Deno or a dot JSON c, which I highly appreciate because package JSON doesn't allow comments, and that's a big pain in my butt.

But the question a lot of people also have is, like, why why not just use package JSON? Like, we're all using that. Wes have to switch to something else now, or do we add it on top?

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.

Nice.

What about publishing JSX, TSX, CSS, Wes? Like, there's there's a lot more stuff now that we ship to NPM, and it's it's always kind of a bit of a trick to to get it working. Yes. Felt files.

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

Mhmm. Yeah.

Like, I I think one of the the great things, and Deno has always done a great job, is, like, sticking to standards as well and the what is it? The import assertions Wes you can Mhmm. Like, import as JSON and Yeah. Hopefully, we'll start seeing as I I think there is there already is a spec for CSS modules,

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.

Love it.

What else Wes got here? What slow types. I I noticed you changed the what the word was previously.

I'd love if you could explain what that means and what the best practices around that are. I think it's interesting for any TypeScript developer.

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.

That's cool.

I I didn't realize that that was a way to to sort of speed up TypeScript because so my next question I was gonna ask you is, like, do you think we will ever see another implementation of the TypeScript type checker? There are many type strippers out there, and there has been 2 major efforts towards building a type checker. I was playing with one of them the other day.

What was it called? Node. Anyways, it's both of them are written in Rust, and both of them are very, very, very early. And I can't imagine having to write a type checker that is the same as TSC. Do you think we'll we'll ever see something like that?

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.

My my other thought of these types of things, I was like, they're probably not gonna happen for TypeScript, but maybe and you're on t c 39. Maybe you can give us a little insight. I know you had a big meetup last week, types as comments proposal or or whatever where I think it was renamed. But, basically, adding types to JavaScript.

And if they build a spec for that, wouldn't it be a lot easier for for people to write new type checkers towards that spec?

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

by themselves. Oh, interesting. I so I I would have thought, yeah, like, Like the t c 39 will come in and say, like, these are the types and and this is how you do it. But they're essentially saying, like, this is your syntax.

Use it for whatever you want, and you can sort of, like, come up with your own flavor of typing JavaScript, which TypeScript will obviously be a be a big, big one of those.

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.

Yeah. We've we've seen things go faster and much slower. Like, some of the some of the CSS spec stuff is just, poof, comes so fast. And then other other stuff in CSS spec, it takes a long time because not because people aren't working on it. Because, like, yeah, there are lots of hard questions that need to be answered for the future of the web. And if you goof it up,

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

Yep. Oh, that's good. Are are there any parts of TypeScript that you don't like? If you were to, like, start it again, would you rip anything out?

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.

Oh, yeah. Because so anybody can overwrite

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

don't override each other. They merge together. Exactly.

Man.

Yeah. See see, it's these types of things that, like, your regular Twitter user does not think about. You know? Yeah. Yeah.

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.

Interesting.

What about when TypeScript breaks? So TypeScript famously does not follow some some there, some bar.

Mhmm. Decorators. There's 2 implementations of decorators in TypeScript. Now what happens are they ever gonna take the old implementation out? What happens to code on JSR when that happens?

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.

Easy peasy. Actually, another question we had was and and you said this earlier that it will be funded by the community.

But, like, what does that actually look like when the community needs to fund it? Because you think about Bauer. So Bauer was a front end package manager about the same time Npm came out, and then people realized we can put front end packages on NPM, and and Bauer is still it's actually kind of interesting. Bauer is still getting, like, $80,000 a year because there's probably projects out there that are relying on the power CDN. So they have to keep that thing up for who knows how long, probably another 10 years or so, and and they still gotta pay those those server bills. Yeah.

But I'm curious what that looks like with JSR.

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

No. It's it's been injecting tracking into all the JavaScript packages. Yeah.

Yeah. That's a joke, by the way. Yes. I know. I know.

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.

Amazing.

1 more question a lot of people had was, how namespacing works. So there's no, like, top level packages in JSR, so you can't just go and grab react. It's it's gotta be at a scope, forward slash. And it's not just your name. You can make many scopes. So, I asked this on the chat, but I'll ask you again. Is there any plan to, like, preregister a bunch, like, at Stripe? Yeah. I I grabbed at react, which I told them they can take back from me, but, like, I was just saying, can I do anything I want? You can have it back.

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.

I'm very proud of that. Scopes, Wes. Don't even think about it. I might grab it right now. I'll invite you as a contributor, though. Oh, okay. Yes. But I like that. Even just like like I'm very curious how Vercel got Npm AI, and, like like, did they grease a couple palms to get that? Because that's a pretty sweet, package name. But with scopes, you can't like, obviously, there's there's nice scopes. Like, I tried to get at UI, but it it was taken already. Right? Like, that that one was probably because, like, how sweet would it be? Like, j s r colon u I forward slash drop down.

But, yeah, there's nice. I don't think there'll be as much of a land grab for that with with scopes, which I think Npm should have done from the Scott, but we couldn't have predicted what that would be like, what, 14 years ago.

High hindsight is always 80 or whatever

it is. Right? I I that's all all the questions I have here, Scott. Do you have any? Or, Luca, anything we didn't we didn't cover?

Yeah. Do you want some,

secret secret new features that we're working on today? Would love to hear the secret features.

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.

So maybe that's Oh, yeah. I don't know. Yeah. You could just have, like, added in this version. You know? It's a it's a method or, like, something's been marked as deprecated with the JS DOM deprecated in this version.

Yeah.

Oh,

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.

So, like, you can see at a glance whether a package works in any given run time. Wow. Oh, that's great. I like the scoring thing because n that's another thing with NPM is you you search for something, and it gives you PQM and a couple Bos. And, like, I don't know what those mean. You know? I'm I'm looking at it. I wanna see. I I kinda do hope that you do, download numbers because, like, I wanna see the one that has a 100,000 installs versus 50 installs because I wanna know which one to to specifically pick. And I feel like those values don't give me. I I just go over to Scott and and look at their stats, which are a little bit better.

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.

Yeah. Yeah. It's or I just use standards as well. Like, that's that's a problem with is Express, obviously, is built on Connect, which is is an open standard, but, like, the standard now is fetch. Right? Everything's built on fetch. So, even our frameworks, Deno Node is is built on fetch. So, it's frustrating when you go and use that because you're kind of deprecating yourself right out of the bat.

Yep.

But, yeah, even Wes JS, 14,000,000 downloads a week.

Request JS was

before.

Yeah. It's been deprecated for for 4 years. I don't think it's had a a major release in many, many years, but it's still super pnpm it's probably used as a dependency on some really big ones, but still.

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

Hano. Very, very excellent. Great work. Yeah. Awesome. Have Hano. Fan of of Hano myself. Is it? I keep saying Node, and I'm always wrong, so I gotta switch.

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.

Oh, that's good. Yeah. And and they just released a, like, they were it works with React components now, and they have, like, a client side state management library. It's pretty interesting.

Yep.

And Seamus plug, where can we find you online? What would you like to plug?

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

we can try JSR soon. Awesome. Yeah. And Andy tells tells me that, late March, early April, they're they're gunning for. So, hopefully, around that time, you can can get it.

Awesome. Alright. Thank you so much, Luca. Appreciate all your time for coming on. This is really fun. Yeah. Thanks so much for having me. It's been great.

Later.