JSR.io with Kevin Whinnery
===

[00:00:00] Hello and welcome to pod rocket. A web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics.

You can try it free at logrocket. com. I'm Noel. And today we are joined by Kevin Winery. He's head of developer relations at Deno slash Deno. We'll leave that up to the listener here to talk about JSR. io. Welcome back to the show. Kevin, how's it going?

Thank you very much. I'm stoked to be here. ~It's ~it's time number three. I know on Saturday Night Live, after you host five times, you get like a blazer. Is it, if I get to five on PodRocket, ~do I get to,~ is there like a jacket that I get at

I don't know. I hope so. Cause then has. Host presumably we'd get some sweet swag too. And

I wouldn't think so. Like you'd probably get like a velvet robe or something 

yeah, I'll take a velvet robe. Okay. Yeah. As long as the producers are on it, we are in action. Let's talk about JSR a little bit. I'm like very naive to this.

So a lot of these questions are like genuine from me as well. Can you give us an overview of like. jSR ~is and ~where it fits into [00:01:00] the, JavaScript ecosystem.

for sure. So JSR is a short for JavaScript registry and it's a package registry for JavaScript and TypeScript. And it can be used across JavaScript runtime. So you can use it. In concert with a node application, bun application, Dino CloudFlare workers, anywhere where JavaScript runs generally JSR packages will work there.

It's notably not a package manager itself. It's a registry. So you can actually use NPM, PNPM, or Yarn as the package managers for your project. And those tools can actually help you manage and install packages from JSR with a little bit more ease. Of with a command that's slightly different because usually they are used to installing packages from the NPM registry.

But with a little bit of massaging, they will very happily install packages from JSR as well. And some of the ways in which it's maybe a little different from NPM is it's designed for TypeScript from first principles. On package pages, we have API [00:02:00] documentation that's automatically generated from a TypeScript source.

We do type checking on packages before you publish. So we look for things that will slow down type checking. If in your TypeScript code, you forgot to explicitly specify a return type for one of your functions and the return type has to be inferred. That slows down type checking a little bit.

So we tell you that, Hey, ~that's. ~This is a thing you might want to look at. So there are a few other features of the platform that are TypeScript specific, and it's also ECMAScript modules only. So in NPM, you can use a combination or support a combination of ESM and CommonJS, although a lot of newer packages these days on NPM are. Choosing to support ESM only. On JSR ESM is ~the~ kind of the only option. So you can write ESM modules and not necessarily have to worry about common JS configuration. Yeah, ~so it's~ it works again, like a cross run times bill for TypeScript and ESM~ and.~ Yeah, we are pretty excited about it.

~It's a, ~it has some really nice features for publishers too, that you can [00:03:00] set up a GitHub integration such that like you don't have to juggle tokens. You can, authenticate with OIDC. It's a lot easier to get publishing from CI set up and lots of niceties that we hope our publishers will appreciate too.

Nice. I want to talk about some of those higher level things here, but I hadn't planned on talking about ESM a little bit. So let's dive into that a little bit. ~What is the ~what benefits are gained by being kind of ESM exclusive? ~Like why, like as a, ~as a registry how can that be helpful for publishers and consumers?

~I see. ~It's helpful for publishers in that you don't have to maintain configuration to have a different set of exports for common JS versus ESM. And generally like ESM, in 2024 has for some time been the web standard way in which modules are supposed to be defined in JavaScript.

We just also feel like it's time to standardize on. ~This part of the, or~ this particular web standard versus common jazz, which, was great and helped the JavaScript ecosystem explode for a very long time. But we do have a different standard these days.

Yeah. ~Cool. Cool. ~I think [00:04:00] that is probably reason enough. Don't spend time. working on and supporting things that are not the norm anymore seems reasonable. I'm curious, you mentioned how JSR is usable with NPM or yarn or whatever your package manager is as a developer.

If you're just like consuming these things, I think it can be hard sometimes to justify like adding another layer of configuration here. ~Like, why, like what, ~as a dev, why would I care about ever like separating from just like the native registry that these things come with out of the box?

~Like, why do I, ~why would I be motivated to switch?

As a consumer, the primary benefit you get is the experience of browsing and consuming packages. The automatically generated API documentation is one of those things. So even for packages that, previously wouldn't have had, online documentation you now get that sort of for free with any packages that are on JSR.

~You also get there, ~there's also some things that we're starting to build out like package quality scores. We in the search results for packages. If the package has complete [00:05:00] documentation if it has passed like our ~like ~fast check rules, which are, which kind of, again, check for some of those ~slow ~slow type rules that those things make those packages rank a little higher in search than they would otherwise.

And we also have the ability to specify for package authors to specify which runtimes they support. We're still building out some of these filters like through the UI, but the idea is like, if I am a CloudFlare workers user, say not every package in the registry probably runs on CloudFlare workers.

So I might want filter only for packages that run in a specific runtime environment. ~And~ And that's kind of part of the JSR design too is it's a runtime agnostic. So we don't assume that you're using node when we try to design ~the~ the developer experience around being good and usable no matter what runtime you're using.

Nice. ~Can we ~can we go underneath the hood a little bit there? Why is that not the norm with ~like~ NPM? ~Like ~why does that not just work out of the box? Normally with the current, de facto.

~Some of the thing some of the reasons why it's ~NPM was designed for node, which [00:06:00] is very reasonable. It's been used by a ton of other projects ~like for, ~there's lots of front end code that lives on NPM as well. But there's just a lot of conventions from the very early days of NPM that still exists.

Like everything gets installed to a node modules folder. Within the UI on NPM there's not really a good way to differentiate between which packages are front end packages only. Uh, there There's some tagging that's happening, but so yeah, I think the, fact that npm was designed for node has left some artifacts that persist To this day whether it's like from the front end ui or ~like ~how packages are resolved and managed locally, too

Yeah. Why do you think as like a project and organization, we haven't reached this level of filtering with NPM? I know we're speculating, but I feel like most devs have this thing. It's ~like~ annoying. You have to go into a package and you're like, go into the readme and figure out ~like,~ will this work in my browser or just download it and try it?

~Like,~ why do you think there's been hesitancy there?

I don't know if it's a [00:07:00] hesitancy. I think it maybe is just about like motivation whether it matters to the maintainers of NPM to create a UX that works really well across run a different, runtime environments And also I think like NPM has at least in recent history probably been like a little under resourced at post acquisition.

I don't know that there's been the same level of investment in it than maybe it's had in years past. So it could just be like hours in the day issue. And also perhaps the, just maybe the motivation to work really well across runtime and provide and make that assumption and as part of the product experience might not be there.

Yeah. Do you think that's becoming more of a problem recently or do you think it was more of a problem before? Because I feel like there was ~I don't know,~ some number of years ago, like eight years ago, maybe it, I felt like that kind of the browser versus server differentiation, I would just run into it more like day to day on like packages that would or wouldn't work.

But I wasn't really thinking about like different node run times as much, ~like~ it was just those [00:08:00] two. And now I feel, the ecosystem, ~like~ between runtimes and just like where node code or node ish code is running has exploded. So do you think like ~we, we didn't have~ we had this problem then we didn't for a while and now it's coming back again.

Or do you think that is not maybe the normative story?

I think it is definitely more of a problem, in this day and age than it has been even, three or four years ago I think like the emergence of Dino and bun have driven some of this need to differentiate between just not assuming that the server side JavaScript runtime environment you're using is node.

I think there's, Lots of different places in which your JavaScript code could be running. There's also, the workers environment, there's the new experimental runtime from AWS that they've put out recently. I think.

runtime? Like once a week, it feels like anymore. Just

Yeah, there's a lot of, which I think is good.

It's good that there's experimentation in this space. ~And ~but I do think like in 2024, like you are not it's probably not safe to assume that server side JavaScript means [00:09:00] node. There's a lot of different things that could. Potentially mean,

~Cool. Cool. So can you tell us, ~I want to get into The actual semantics of how, one would ~public ~publish to JSR and stuff like that. But can you, while we're on this kind of tagging and filtering system, can we explore that a little bit more? Like, how does that actually come to fruition and then look in implementation?

yeah. So within a JSR, after you publish a package within the setting, there's like a settings UI where you can specify which runtimes your package is designed to support. So we did it this way. So package authors could control like. Essentially what they claim to support in terms of runtime compatibility much like you might, if you were publishing a game, you could say yeah, it runs on windows and Mac and it requires these graphics cards or whatever.

~You, ~you have the ability to say this is what I certify. Yeah. My code runs on it may work in other contexts. Like I may say it works in, bun and no jazz, but it could work in Dino and browsers as well say. But we thought it would be better to allow the developer to declare the sort of [00:10:00] surface area of runtimes that they support in packages.

What that'll manifest as ~you~ you'll You know, flip a couple boxes in the UI and then within search results and on a package overview page, there's bits in the UI that will show you which run times are supported for a given package.

Oh, cool. ~Is it, is there anything ~as a consumer, is there anything that can happen? Like. When installing packages is there any kind of runtime detection that'll come up and be like, Hey, this might not actually work in your, in the runtime that you're using

Not yet. We do think eventually that will be something we want to do like in the installation step. So like for Dino, you can. Add a jsr package to a project in like into your import map Or you can also, you know directly within source code. You can import a package directly without an installation step And we think it would be nice to be able to detect dino support or lack of dino support in a module and then You know print out a warning or something like that.

We also have a command publish on [00:11:00] NPM that you use to manage NPM dependency or manage dependencies in the context of like an NPM compatible project and that utility, we'd like to be able to reference that as well. But today it ~does not~ does not do that.

now. And that's what, let's roll back a little bit. So when we were talking about ~like ~supported runtimes for packages and you mentioned how the authors tag them, is that all ~like ~done. In the UI, or is there a way you can have this declared, like within your. ~Like within the ~project in files as text somewhere 

It is in the UI today however, we have a JSR. json file which is the configuration or the metadata configuration file for a JSR package. Or if you're using Deno, you can put those in a Deno. json as well. And~ it, ~it isn't supported today. It's something that we went back and forth on a little bit.

But I think eventually we are going to support configuring like much like you have like the engines field in a package. json where you can like a. Kind of doing a similar thing within the configuration file.

Yeah. ~What was the, what was some of the, like the debate centered around there? ~What were some of the cons of potentially doing it that way?

There is value [00:12:00] in having it, having some configuration be dynamic ~through the ~through the website, just because then you don't have to change code in order to flip the bits on these things, and then push up an update and that sort of thing. So there's a bit of convenience and.

Also, I think it yeah, that was the primary like DX debate. Also it was just like another thing to do. We were definitely very busy trying to get JSR out the door and

Oh, sure.

A browser based implementation of it. So I wouldn't actually be surprised to see this show up as an option in the configuration file.

But yeah, ~it would, ~the minor debate was around if it would be more ergonomic to have it in one place or the other.

Yeah, ~that's ~I'm not trying to like minimize the amount of work that goes

know. Yeah, no way for

No, that's but yeah, it's always just interesting to hear, especially when teams are working on these kind of okay, we're trying to build a tool that will be ~like, yeah,~ usable by devs.

What are the UX decisions we're trying to make and where are we willing to make compromises? But I think that's a decent segue. Let's talk a little bit about how ~like ~publishing to JSR works. It's say you're a package maintainer and you're just like publishing to NPM right now. What else do you have to [00:13:00] do to get publishing to.

JSR.

depends on what's happening in your package, but the smallest amount of work that you would have to do is in addition to a package. json, you would have a jsr. json, which has, the metadata information about your package, like your scope name scope and package name together, the version of your package, and then~ a.~

~Like~ a set of exports. So you specify the path to source files within your repository that contain the interfaces that you want people to be able to import from your package. And those three configuration things might be all you need. Like if, especially if you have an existing ESM or TypeScript code base, you might just be able to point JSR at those files and they mostly ~publish~ publish fine.

The. Thing that you probably will have to configure if it's a node package is something called it's a little bit cheekily named, it's called sloppy imports which is like a configuration option in [00:14:00] Dino where you can choose to have imports that don't explicitly include a file extension.

There's just, there's a minor performance hit that gets incurred in if you don't require file extensions where you have to introspective. A directory and figure out like, is this a dot TS file or a TXX TSX file, et cetera. But if you enable that for a node project it's just like a command line flag that you can pass in.

Then ~you can largely use your node code. ~You can largely publish your node code unchanged. There are some other things that in the node world you might run into but ~it ~Specific to, what features of node you're using. And~ if you are, ~if you do have a TypeScript code base ~there, ~there are some features of TypeScript that are discouraged on JSR that you might want to work through.

Or maybe you've Don't always explicitly include types on your unlike the parameters to functions within your sdk or explicitly defined return types You'll get some warnings. You can actually choose to skip those if you want And publish those anyway So I think like the level of effort to [00:15:00] migrate is usually dependent on if your TypeScript code base is fairly clean in terms of types and what features you may or may not be using in NPM, like you might have to configure some things slightly differently, but that's actually like the big focus for the team right now is we're going through lots of existing features.

Large code bases and publishing them GSR and figuring out okay, like these are the corner cases where we need to support X, Y, or Z configuration in order to allow for the least amount of work to publish these existing code bases, GSR,

~Let's say again, ~let's continue with our example and you are a package maintainer and update and let's say it's like a pretty active package and you're pushing new versions out all the time. Is there any differences in versioning or anything that have to be taken into account or do they function similarly with Semver?

Yeah, function similarly with semver. So you'd probably use the same versioning scheme for both your package on GSR and for your node package. Or your npm package 

~yeah, I gotcha. I gotcha. Cool. Is there any ~I know you mentioned a [00:16:00] couple there, but are there any other common like errors or problems that can occur that might be something new that like people haven't encountered before when trying to publish to JSR for the first time?

I think it's largely going to be around ~the you know ~the import like how you have your imports defined ~and the ~and if you're using typescript~ You know ~your adherence to a set of standard runs standards around typescript other than that. There shouldn't be a lot That is ~that is that ~much different ~from a ~From a publishing workflow standpoint,

~Gotcha. Gotcha. Is there any I'm trying to think here. ~Are there any other limits that might be encountered? I don't know, just with size or anything ~like ~that may be worth keeping in mind or plug and play for the most part.

~There should, ~you shouldn't necessarily run into size limits. ~I think there, I don't remember what it is off the top of my head. ~I think there might be a maximum file size~ for just, ~so you can't necessarily, include like a DVD image or something in the disk image in the package.

But~ Yeah I, ~for the most part, ~I, ~there aren't major limitations. They, so the implementation of JSR uses a GCP behind the scenes. Most of these assets are being stored from Google cloud storage bucket [00:17:00] which have pretty high limits and are ~reasonably ~reasonably highly available.

So it's~ yeah, ~generally not a limitation you have to consider.

~Nice. Nice. I had one. And one more, ~one more question that I've just been landing on while we've been talking a little bit. And I think one of the common things, I don't know if it's as common a gripe as it was before, but it always is coming up again and again is like security around NPM, right?

Like just people pulling in tons of packages. Are there any differences there? Or~ just ~did JSR do anything different? And if so, why, and if not, why not?

so not there. There isn't anything that's being done differently in terms of auditing a package for security issues. The one thing that is maybe slightly different behavior is packages on JSR are immutable. So you can't necessarily pull down a package ~that ~after it's been published to avoid like a left pad situation where you know There's something that just happens to be dependent on by a lot of the ecosystem You can yank packages such that they won't [00:18:00] appear in search.

Anymore and ~there's ~there's ways And you can also like work with our support email directly. If you absolutely need to delete something, there's a way to do it, if there's sensitive information that leaks or something like that. But yeah, there

In those cases.

is a human involved~ in those~ in those cases, but yeah, there isn't a lot that we've implemented that NPM doesn't have in terms of like ~security. ~security concerns. So like ~within ~within Dino specifically one of the things with the runtime there is you as a developer have to opt in to allow your code access to the file system, to the network, to system and environment variables. At the runtime level, there are some security guarantees that you can have that sort of.

Limit the damage that a malicious package can do. But at this point JSR isn't doing anything specifically on that front.

Yeah. ~That was ~that was my next line of questioning as well, because I feel like last time you were on, we spent a lot of time talking about~ that kind of ~those flags in the way in which you could isolate the capacity of like packages as you [00:19:00] relied upon them. Is there any other.

Kind of magic is the wrong term, but I noticed like utility say you're running Dino is there any other kind of niceties you get out of the box by using something like JSR instead, or is it largely agnostic?

The primary benefit you get as a Dino user for using JSR is the. fact that Dino can now do a deduplication of dependencies. The sort of previous state of the world in Dino was used HTTP imports to pull in dependencies from, a fully qualified URL. And that's great for a lot of scenarios and actually still works in Dino and will work into the future, but it prevents Dino from being able to, detect.

Duplicate dependencies and do optimizations such that you're not downloading multiple versions of the same dependency when, a single version would satisfy the needs of all the consumers. So deduplication you get as a part of this. We also would encounter situations with [00:20:00] disappearing dependencies.

So if there was a server that was hosting a dependency that a lot of packages depended on and there was a problem, it went down. Then that could end up with a lot of builds breaking as a result. And Dino did allow you to vendor dependencies. There are ways around that, but it was a fairly common problem.

Whereas with JSR being a centrally managed repository, we can be reasonably certain that we can keep that infrastructure available kind of at all times. So deduplication and stability are the two big benefits. In addition to like the UX of JSR that we talked about before for packaged consumers, like you also get to have docs on everything for free and also the quality ratings and the search capabilities and an expanding list of, nice features there.

~cool, cool. Are there, ~for Dino module maintainers or package maintainers at large, maybe, is there ~like~ anything that they need to do to migrate from those URL based? Imports to ~like ~have users start pulling their code in via [00:21:00] JSR. Is it largely the same?

So end users that are like have Dino code in production that use HTTP imports can continue to use that kind of unchanged. And they could also migrate incrementally to JSR. If there's a particular dependency that is on JSR instead of Dino and X they can swap that out either in an import map or directly in source, depending on how they were.

Managing it previously. So it is possible to use both at the same time there's also a for like package authors that were publishing to dino landex and there that we have a utility that helps With that migration so you can run this utility in your package And it will do a lot of the refactoring that we expect is going to be necessary to move your package from slash x to jsr And then the fallback for that is if you have some HTTP dependencies that are reasonably gnarly, you could actually vendor those and then publish your package to JSR that way as well, it is a little bit duplicative, [00:22:00] but it's probably the quickest path to Like taking a Dino land X module and putting it on JSR is to, vendor those dependencies ~if~ if all else fails, but yeah, so there's a few different ways you can go about migrating.

~Is that kind of the new, ~are you guys ~like~ pushing this? ~Is, ~are you hoping this becomes the new standard instead of, land slash next, or is it like going to try to maintain both or not maintain, but, let users use whichever they want for as long as possible.

Yeah. We definitely are going to start pushing folks towards using JSR with informational messages, like starting with Dino 2. 0. We'll just start detecting in projects that are using HTTP imports from Dino and acts like. Trying to nudge them to use a JSR so that largely be, we actually aren't going to be discontinuing Dino land X at any point, like we, plan to actually maintain it indefinitely.

And we won't be removing the ability to do HTTP imports from Dino either. But because JSR. Packages have the benefit of being able to be deduplicated and [00:23:00] being a little bit more stable, we would generally consider it to be like a safer, nicer route to use that by default versus Dino Landex.

So we will be nudging, but not really considering at this point, like deprecating or shutting down any of that other stuff.

~Cool. ~Cool. Yeah. ~That that, ~that makes sense to me. ~Is there, I guess I'm ~maybe as a closing point here, I'm curious why you guys chose like this level to cut into the existing module ecosystem,~ like why? I guess what, like, ~why did you choose to continue leveraging ~like~ existing package managers, like NPM or Yarn, but you wanted to get in at the registry level in particular versus and we'll just do a whole new package manager that anyone can use.

~Like ~what were the trade offs when you guys were doing that evaluation of ~like~ where to step in here?

~Yeah, that's a, ~it's a good question because~ as we were think ~the problem that we were originally trying to solve for a couple of years or like trying to think through for years was the deduplication and disappearing dependencies problems that we talked about earlier.

And we went through a few different ways to go about [00:24:00] solving it. And one of the ways to solve ~it, ~it was theoretically just to use NPM and just say okay we. NPM exists. We could use this to manage packages in Dino. And this would be the bag of trade offs associated with that.

~And probably the biggest thing that kind of led us to wanting to go a different, or ~there's a couple of things that led us to ~one, ~want to go a different way one of them being the. Efficiency of HTTP imports was really nice in Dino because you could only, you only ever downloaded the actual files that you included in your project.

So you weren't by default downloading huge tar balls that had like tests and read me's or whatever in them. ~So there, ~so that was really nice. And we wanted to retain that if at all possible. And then the developer experience of using NPM would always be just like a little weird in the context of Dino.

~Like ~Even small things like on a package homepage, you would see, NPM, I this module and run it with node and in this way. And they're just like, it wouldn't be natively aware that, a package would be used in the context of Dino. So it felt like it would be hard to.

Provide like a [00:25:00] first class developer experience using NPM alongside, so that kind of led us in the direction of with JSR, like we want to maintain what's good about HTTP imports, which is the efficiency. And that's actually what's happening behind the scenes with JSR. Like it's HTTP imports in a trench coat, like it's using a lot of the same functionality.

It's just has this layer of semantic versioning and deduplication that sort of sits on top of. Yeah Set of logic. And then we also wanted to build out the front end in such a way where it would be runtime agnostic. And that was just ~like ~something we wanted, we felt was the right thing to do anyway, ~is ~I don't think it was necessary to design this as like a Dino.

Package registry. Really what it was, it was a TypeScript and ESM module registry and building in such a way where it could be used at any runtime in any environment. Felt like the most utility to the most people. And it's also like why we decided to open source it independently and run it as [00:26:00] a separate project.

Cause we just feel that there's not really actually a need to make it tightly coupled to Dino either.

Gotcha. Cool. ~And was there any,~ were there any compromises that you guys had to make to continue supporting like NPM and Yard and like other package managers? Are you able to leverage or take advantage of all that utility you just described, but still have support for these things?

Or was there any small trade offs there?

There are some ~like ~tradeoffs in that so JSR integrates with the native NPM clients through existing functionality. So ~like ~in an NPM client, you can specify that, packages from a certain scope are loaded from a registry that is not NPM. So you have the ability to have.

Custom registries, and that's actually what we've implemented for J. S. R. There's sort of an N. P. M. compatible registry like H. D. P. A. P. I. That these N. P. M. clients interact with, and that does have to behave in a certain way. So there are a set of constraints to put on what we can do with packages [00:27:00] in N.

P. M. Because of that. But yeah, so I think probably the primary trade off is we aren't able to make the package installation process any more efficient in NPM based projects than it would be anyway. So it's bounded by however good that experience already is. Cause we're just participating in that ecosystem.

So in a sense, that's a trade off, like it's not, it doesn't necessarily get better for you. But it works the same way as other dependencies that you would already interact with.

Cool. Nice. Have you guys had any. ~Yeah. Absolutely. Like extra, I don't know, like~ user support overhead here for devs that are coming in, that are in, ~like~ existing yarn or NPM projects as their package manager where they're like trying to pull in JSR packages and it's proving problematic Or is that if people ~have, people that ~have delved deep enough to be that at that level are largely ~self, ~self serving.

~We, ~we've definitely had a few issues come in around just cases that we hadn't considered or configurations that we hadn't tested, as you can imagine there~ would be, it ~would be many of those. But ~for the~ for the [00:28:00] most part, it's actually seemed to hold up reasonably well.

Like for most of the common workflows for node and NPM projects JSR has pretty Tended to work pretty well. There are definitely some things we still need. Not some, there's a lot of things we still need to do to make support like really great. Some really basic stuff like that just didn't make it into the public beta release supporting JSX files as a part of a package today that's not Currently supported.

So ~we want, ~we need to make it possible to ship those kinds of files and like other kinds of files, like ~a static~ you can ship static files, but we want to, ensure that you can ship view files or dots felt files or what have you as a part of your package as well. So ~there, ~there's a few things like that.

We need to figure out And also for packages that make use of~ like work ~workspaces from that are in the NPM ecosystem today. There's a little bit of like unfortunate monkeying you have to do to get those packages to publish ~on it ~on JSR. And we, so there's definitely been a few of those like UX issues that we need to [00:29:00] work through.

It's definitely beta software we knew that there's going to be a lot that we still need to figure out and like parts of an interfaces that the community would find not great initially, but thus far, ~like ~I personally have been pleasantly surprised at how well it has worked~ be ~just because of the large diversity of ways people can configure npm projects

~Cool. Very cool. Yeah. You can't, ~you got into it a little bit there. I was going to ask what's on the roadmap. Is there ~any, ~anything else that's on the horizon that you're particularly excited about?

Yeah I think the thing i'm most excited about is broadening the number of npm modules that you can publish to jsr with no configuration changes like as we've been Going through ~like ~the most popular node packages and just ensuring ~like ~that they are theoretically publishable ~to ~to jsr We found a lot of things and I think we're nearing a point where you know in the coming ~like ~week or so it should be possible to take a lot of those types of existing typescript code bases and just ship them to JSR without [00:30:00] very many changes.

So excited for that to happen. I'm excited just because ~like ~we've seen pretty good adoption, like there's going to end up being ~like ~a lot of the packages that you would expect to find on a JavaScript registry are starting to, slowly get, the JSR tooling in place to start publishing there.

And then we are also looking at ways of supporting kind of dual publishing so that, as a module publisher, if you want to have your package exist on both NPM and JSR, which very likely you would like, say your Stripe, and you have Stripe on, ~and ~the NPM registry, you probably want to continue to publish there.

So ~like ~we. Want to make the tooling in JSR really nice for doing that. So you can still get to just have a TypeScript source that you publish directly to JSR, which is another nice city. If you're developing in TypeScript, you can actually just publish source files to the registry.

You don't have to do transpilation first, gSR will actually handle that for you. And like in the context of a node project, it'll send transpiled files with. d. ts files along sitting alongside [00:31:00] them as a part of your package. So you can just have a TypeScript code base and then handle and have transpilation handled for you.

And in a similar way, it would be nice to just handle publishing to NPM on behalf of developers as well. So we are looking at different ways to do that in an ergonomic fashion. There, ~yeah, ~a few things we need to work out still, but~ that, ~that's something that I'm pretty excited for too.

~nice, nice. ~And I'm bouncing around a little bit, but you've spurred another question from me and that, and you touched on it there. I was going to ask have you thought about making it? So all of the JSR packages like automatically, published back up to NPM. And I'm also curious, like on the inverse, you guys talk about all the work you were doing.

So test compatibility and make sure things work. Did you consider, or was it ever on the drawing board of like just pulling in the top, whatever X NPM packages automatically and having those available.

It was something we talked about ~it. ~I think what we'd. ~would ~largely prefer is to like work with the teams maintaining these packages and just make sure that they have the support they need to, publish to both registries if [00:32:00] that's something they ultimately decide they want to do. But yeah, it was something we talked about.

It seemed it might be surprising to take agency away from the maintainers of those packages in that way, but we certainly have been like testing with a lot of those packages. So

~Cool. That makes sense. Cool. ~Is there anything else you want to shout out or just direct people toward if they're looking to get involved like in the project?

yeah, for sure. Like I said, JSR is a free and open source. The GitHub org is, github. com slash JSR hyphen IO. So if you want to check out the source, see how it works or contribute to the project we've actually already had, I don't know if it's hundreds, but we've had a lot of pull requests and like small contributions coming in from folks out in the community already, which is awesome.

And we want to continue that. We also want to and we'll continually try to figure out the best ways to engage people in this, but we want to involve more people in like the moderation of packages on JSR too, and have a degree of community governance ~over like the ~over that.

namespace and [00:33:00] just find more ways to get people involved in the day to day operations. So in the launch blog post for JSR, there's actually a form you can fill out if that's something you're interested in, if you want to be involved in the conversation around the governance of JSR. It would be great to fill that out and let us know, and we can start roping you into those conversations.

And yeah, just generally trying out JSR would be great. It's, ~it is ~really easy to publish a package. If you want to try publishing, it's something you should be able to do in, just a couple of minutes following the documentation and just letting us know what's what's broken~ we, it's, ~it is a We think hopefully a pretty nice developer experience right now, but there's tons of stuff we still need to fix.

So letting us know what you encounter would be much appreciated.

~Nice. Nice. Awesome. We'll have, ~we'll get a link to the website and the show notes. People can find all that stuff from there. Hopefully. Thank you so much for coming on and chat with me, Kevin. ~It's a, ~it's always a pleasure.

Yeah, it is always a pleasure. Super fun to talk with you every time. So thanks for having me.

Of course.