JSR: The New TypeScript Package Registry (NPM Killer)

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, HTTP, which is kind of similar to how NPM does it because Npm is generally very slow.

The way it works by default is that it looks at the version inside of your, or, I don't know, in the bottom 99,

And then it goes and publishes. And this is sort of 2FA. And and

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, Yeah. Yeah.

or sorry, tokenless publishing

to use

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.

imports that way? Or

first announced, the big thing was

And it'll, like, understand the, like, files section of the package JSON and the dependency section and all of that 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, pay membership dues.

the import map inside of it. And this is what we recommend people to use. And this will work totally fine with the JSR.

Like, we we've we've thought about this, to to make sure that it's difficult for people to You you you can just see that, and search there where you can search

which is really nice. And under the hood in Deno,

For those who are familiar, OIDC tokens,

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.

is sort We don't have to worry about this backwards compatibility issue.

Mhmm. And, you know, then became the whole DEPS file thing, which was essentially Yeah. Thank you for that.

or has had in the past, and and we're trying to not repeat those mistakes.

we want to we're we're doing the same thing for publishing from GitHub actions,

installing from URLs

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.

when you merge something into a branch and a member of TC 39. So

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.

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? on, like, every single commit, or does it only go on when you tag a a release on GitHub?

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

pnpm map and just inline them into your source code so that Because Wes.

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.

was

And when you're publishing a package automatically assign scores to packages based on So

publish maliciously and to sort of avoid a lot of the pitfalls that it came has, to be able to ensure that the person that is publishing a package, 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.

possible, like, did you know company JS well funded? And we have revenue sources. And we're totally happy to,

Yeah.

Is is

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.

which 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 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.

I know this is not Dino's package registry, but do you do you all see this as being the way forward for Dino?

integration is is pretty neat. Does that publish 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

during installation or or the consumers of your code don't need to actually then know about your bookmark, but rather,

Cool. I I know that, you know, when Deno

only.

just a package file, you know, of imports.

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, 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 forget how many it is, declare global

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

build setup that maybe understands node modules, This is absolutely not how we want to operate JSR. JSR is going to be a a community resource. JSR will be open source.

encounter an error and you you get a stack trace, it actually shows the original source rather than the JavaScript.

If node Wes ever to support using TypeScript natively, then, Oh my god. What Wes what we did is, we And this is not really how we want JavaScript to progress. JavaScript is a very dynamic language.

JSR have any

if you're gonna have some like internal team at Google that has a predetermined 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 common JS pnpm, whether you have a read me, whether you have a license,

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,

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,

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 the Scott of top level interface of that module and not the actual implementation details.

is actually who they say they are. We also

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? CSS,

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,

which, 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, But, Npm It it'll be very cheap for us to operate.

is wild. Like, yeah, I'm just gonna download this random code

I don't see NPM doing it anytime soon. Right? Like the the last big feature they launched Wes, I think, package provenance, and certain ESLint and things that are just built into the red to the registry.

Well, you that that's my next question is,

Yeah. So, the the way that works is that for tools that support importing TypeScript natively. So for example, Deno, if you're importing from NPM, all packages 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 if you'd asked me 3 years ago, I may have said yes. And then after seeing like And, yeah, we'll we'll be announcing more about how we exactly,

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

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.

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.

being able to scan dependencies, and then we also had

is actually the not by a single company.

Sure. You can try.

Package fragments. It's like a it's a security feature to be able to ensure that

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.

for the tools that do not natively support the system, give them a way to easily downgrade.

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.

strip out all the types. So we're turning it back into plain JavaScript.

And this

which is pretty interesting. So does

like package provenance, even though FS package, you could do at Wes slash 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.

Darcy was talking about a big part of Vault was,

on from,

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,

all the tools that you want to consume that package in now need to have some additional tooling set up.

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 Terrible at shameless plugs. You could tell.

you can ship any files you want. People put movies on NPM. You know? which

we'll just give those tools the TypeScript files directly.

And there's a new mode that they're introducing called isolated declarations 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, like, all of the configuration and dependencies are described in the source code,

assertions

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

func types that need to be inferred and are thus slow, slow the the good thing about TypeScript is that

Solatype. So this is needs to needs pnpm explanation for those not initiated. Yeah. TypeScript is a very dynamic And with NPM, 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,

install is also just downloading a bunch of tarballs from HTTP. Right? It's it's really nothing other than

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

slightly more complicated HTTP 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.

what is it? The import the rogue ones,

other files like Wasm files, 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,

a nice easy to use friendly face.

in this inference because TypeScript doesn't then have to do inference if you already explicitly specified return type on a function, for example.

Vercel file or or view file. Or moderation team that will be based not just of contributors of Deno, but of the whole JavaScript ecosystem.

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.

So

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

And what this does is it saves a lot of time 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

and and what way you can

What about publishing

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

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.

Nice.

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 Just how TypeScript works. Right? And if you're then consuming them from Node, they'll be transpiled.

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

JSX, TSX, 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.

TypeScript files are transpiled to JavaScript. JSX files will be transpiled to JavaScript.

And then CSS, something similar will that'll work just fine. If you're

Mhmm. Yeah.

Yeah.

that it's sort of like strict mode in that it adds some more rules around what you have to do with TypeScript.

through regular JavaScript 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

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.

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 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 Amazing.

Love it.

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.

that are going through TC39 Realistically, like, if you're writing a new project, you're writing it in TypeScript.

as source. So you don't have to transpile them before publishing them.

you don't see it, but actually they should be specifiers,

to ship that maybe, I don't know, a couple months.

publishable,

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.

JSX and TSX files will be published to pay for JSR. This is like a community

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

Just how, distribute your packages.

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, through symbols. You can search through the JS doc. You can search through symbol names, the parameters, the return types.

imports.

this is a this is a really good question.

I I like, Wes is posting

like, $80,000 like, can't NPM? Just

And the the completely honest answer is

this this has solved so many issues that we have. And and so many people's complaints about

And this conversation

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.

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

some in our in our show notes some screenshots of when he tweeted about this, a lot of people responding why.

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

I think this is just a great,

the the CJS ecosystem, so many complaints about the TypeScript ecosystem.

just chipping in all the time. Yeah. Yeah.

that has members from many companies and those member those member companies maybe they should be pushed more than packages that haven't be been updated at all in the last 3 years warp that have And after that, you can just run NPMI.

the emit and they don't

So

Backwards compatibility. This this only matters if you're checking, for Nothing else JS set up.

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 Later.

Initially, 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.

we don't really know exactly what it's going to look like yet because,

Bauer. So Bauer was a front end package manager about the same time Npm came out,

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, 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.

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

that is

okay. It's a new package registry to, that

That there's

the community needs to fund it? Because you think about

you know,

And I think it it like, the TypeScript has the stance that they don't break in NPM search

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,

a year all of the the benefits

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,

who knows how long, probably another

answers that why question for me in so many ways that I feel I went from,

because there's probably projects out there that are relying on the power CDN. So they have to keep that thing up for NPM? Why do we have to have something Why can't you put your time into fixing NPM? It's a great question.

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.

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 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, And, yeah, this NPM RC file just sets up NPM to download anything in the Wes 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, 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

Yeah.

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, 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

all tooling surrounding it, the docs, everything will be open source.

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

not by a single company. It needs to be paid for by the JavaScript ecosystem, and click on deploy, and it's live in like 3 50 regions and what, 2 seconds.

it's really difficult for them to do. And when you make things easier, 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? some crazy minified bundled

But, yeah, if other companies want to engage here, this is something where we we'd be totally happy to, like, then Yeah. Find me on Twitter.

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,

makes it authoring and publishing But, like, what does that actually look like when JSR, you can still use with NPM.

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.

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.

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 think that this might be the the next evolution of that. So

And,

by the JavaScript community, not by any individual company.

will have a 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.

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

people make cooler stuff. Case in point, totally outside of the JavaScript registry, I asked this on the chat, but I'll ask you again. Is there any plan to,

let's TypeScript

extensions for Raycast like, they were it works with React components now, and they have, like, a client side state management library. It's pretty interesting.

that we can pull directly out of your source code as compared to, like, transpiled JavaScript or d.test Wes.

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.

which is, I

these modules, 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.

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?

certificates and whatever. Right? And now you write some JavaScript in, like, cloud cloud workers.com based on the differences in your symbols.

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

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.

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

And

the hosting of of JSR?

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,

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

Node understands CSM, Cloud understands CSM, Cloudflare understands CSM. Everyone understands CSS. Do you know understands

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%.

CSM. So why not just only use CSS? Right? And then TypeScript is the most popular,

and a couple Bos. And, like, Is it the new NPM? Is it a new package registry? 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.

Yeah.

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,

before.

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,

Oh,

Sick. Well,

a 100,000

Request JS was

pizza cutters,

dev, l c a s d v.

and Hono JS really awesome.

And,

And Seamus plug, where can we find you online? What would you like to plug? What about when TypeScript breaks?

download numbers because, like, I wanna see the one that has That NPM specifier thing. So if you you're trying to imagine it right now, it's if you wanna import something from

Change logs, which is the same way that browsers work. It's it's well defined behavior.

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.

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.

probably Wes wanna integrate change logs natively at some point. Yes. And we have docs. Right? We have docs for every Vercel. So like looking at the tarball and and transpiling TypeScript to JavaScript, this could be a viable approach, but Npm doesn't. And, You have we've put a lot of effort into making automatic publishing, 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.

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

kitchen utensils,

have documentation and have been updated in the last 3 years, and this it's everything is immutable in such a way that it's very, very highly cacheable.

static analyzability

Wes and I have sick picked podcasts, YouTube channels,

Yep.

deprecated

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

in this version.

anything you would like. And then a shameless plug is just anything you would like to plug.

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.

10 new issues every day or whatever. Yeah.

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

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

I don't remember what handle is. I think it's how

late March, early April, they're they're gunning for. So, hopefully, around that time, you can can get it.

something's been marked as deprecated with the JS DOM like, preregister

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

Yep.

Deno Node is is built on fetch. So,

things like the quality scoring and and the documentation generation. And I'm sure we'll come up with other things, you'll be able to run JSA or publish, and it'll just pick that up as the file.

this version. You know? It's a it's a method or, like,

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

we can try JSR soon. Awesome. Yeah. And Andy tells tells me that,

let me look it up real quick.

you go and use that because you're kind of deprecating yourself right out of the bat.

with modern features and, like, based on what our protocols and Yeah. Do you want some,

automatically generate change logs

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 if you write your packages only for node, long pros, anything. Right? types.

indicators for different run times. You can, like, market packages compatible with Node or compatible with Cloudflare Workers or Athena.

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,

I'm just reading the source, reading the inputs and outputs, reading the comments. So, taking

you don't have to generate the d.ts files. Right? Deno vision still

Is that just, you know, but, like, do you see

Wow. Yeah. That's awesome. And,

understand more about the libraries instead of going to,

Yeah. I've gotten so used to this flow after working in Rust of using Docs RS to to just

you know,

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.

be working similarly to how you're doing the automatic docs? Is that the scoop? Sign up, and you'll get 2 months for free.

quick start documentation.

And rather than have to

in addition to that, I mean, there's the auto types thing so that

generate some d.ts

to have to do. I'd rather just require The the config file is a j s r dot JSON or Deno

to to do it that way.

put them on at types and npm install them. That's such a pain

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 then boom. Like, all the docs. It, obviously, is a small library, but all the docs are just automatically generated

and then I exported a couple TypeScript then I also wrote some JS doc on top of it to provide some examples.

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

yeah, this is, definitely something that I'm happy to see.

It's it's pretty nifty.

because hey. Why not? Right? Like, these are this this is the kind of thing that,

files and

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, I'm I'm here as a Initially, did you Node company will will pay for out of the box.

and I fragments?

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 The the GitHub action

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,

moderator program as as we get closer to launching JSR.

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?

Yeah. Already got it. You're Scott, like, a top 1,000. But, URL. And this this just gives them a nice facade, 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.

packages and scopes from from NPM. We have sort of preregistered these. Well, they're not really preregistered. They're sort of in a,

yeah, yeah. I don't know. All these fun things.

if if somebody tries to register Wes, But I think it like, nobody's done this over the past All of JSR will be open source. All the back end, the website, explicit return types on all functions because we could have much faster type checking if they did. Interesting.

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, the WebAssembly community group right now that would just allow you to import WebAssembly files

obviously, of down the same,

I think this will be fine.

they probably can, unless you've already registered that. I don't know.

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

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 It is not a junior registry. It is a ESM and TypeScript

state where you as an individual cannot register them without emailing us first,

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.

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, So maybe that's Oh, yeah. I don't know. Yeah. You could just have, like, added in

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

want to set up this this community, So this is sort of a

And we don't think that 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 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.

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

1 more question a lot of people had was,

policies. Right? 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.

The the way the way Wes like, we don't have these top level packages to prevent, TypeScript will work. Everything will just work. Beep will work.

We're not completely sure about that yet.

There's ways where we could set up a GitHub Sponsors thing where individual people contribute. Right? 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, Yeah. Absolutely. So because you're publishing TypeScript source code, we have a lot more information

whether your code is formatted,

it is. Right?

documentation,

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

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

High hindsight is always 80 or whatever

you can't like, obviously, there's

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% What we're trying to do first is is launch this, see what the reception JS. And, that'll, yeah, be able to provide a lot of value to to users. Actually, one thing we did mention is, like, we have,

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

how Vercel got Npm AI, it's frustrating when

there's nice scopes. Like, I tried to get at UI,

certain factors, like whether you have

you know, people from squatting

package name. But with scopes, downloads a week.

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

I like that. Even just like like I'm very curious

all of all the scopes.

and, like like, did they grease a couple palms to get that? Because that's a pretty sweet,

but one could be absolute numbers.

what that would be like, what, 14 years ago.

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 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.

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,

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

and he maintains Redux as well as a couple

on the podcast,

a Deno only thing. This is going to be a package registry for

but,

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.

or sorry. Not even going all in. Like, you can still use common JS packages, Yeah. That's a joke, by the way. Yes. I know. I know.

anybody who consumes JavaScript. Right? 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,

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

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.

That is absolutely correct.

We had, Mark Erickson

Man.

the meaning of all the types, I think it would.

isolated declarations are Microsoft, Google, and Bloomberg,

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

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,

anything shifts. So we'll see. I and and, like, the tie I know there is no time line for that,

Yeah. See see, it's these types of things that, like, your regular But, yeah, even Wes JS, 14,000,000

Yeah.

The the people that are pushing if NPM natively supported, 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.

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

That's cool.

That's member of the general company right now, but JSR

is up to the tool that's going to be interpreting them. Oh, interesting.

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 Yeah.

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.

5 years or 2 years? You know?

Interesting.

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.

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?

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 We will have support for features you know, JSON or JSR JSON file.

and it's like well defined behavior. Right?

Oh, okay. Cool.

Oh, yeah. Because so anybody can overwrite Volt,

If if we were to go down a path where we like very explicitly

Twitter user does not think about. You know? Yeah. Yeah.

just make the one that we got faster. So hey. Yeah. That's not an it's not a a bad solution.

if you take

types as comments proposal or or whatever where I think it was renamed. But, basically,

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 We we expect to be able to do this for a long time. It'll it'll be very cheap to operate.

So TypeScript famously does not follow some some there, some bar.

but

and export equals

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?

type checker?

at the cost of of some convenience, we're really betting on the Wasm imports proposals 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,

companies that have very, very large code Bos with TypeScript deal with, like, APT to install Nginx and, like, manage

and there has been 2 major efforts towards building a

Yeah, the TypeScript emit is stable. So for any given version of TypeScript,

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

implementation out? What happens to code

specify

If to decide,

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 forward slash. And it's not just your name. You can make many scopes. So, So that's that's the kinda thing that we need to drive home here is that plans

for the future of the web. And if you goof it up,

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

You know, I

and they don't really have a a semantic meaning

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.

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 in their companies.

you have to explicitly specify more types going to significantly improve the the the problem here in in the next couple

type checker. I was playing with

type check differently somewhere at the top of the tree because you've changed the fetch types. Right? Yeah. And interfaces importing from BUN, which supports TypeScript, that'll work just fine without any transpilation.

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

of these types of things, I was like, they're probably not gonna happen for TypeScript, 10 years or so, and and they still gotta pay those those server bills. Yeah.

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, 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.

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, we just wanna make it super easy for you to get to what you're looking for.

We to do enums are sort of a a a feature that does just transpile away, but rather,

one of them the other day.

months, maybe years. Oh, that's exciting. So maybe that's really the solution. Instead of rewriting the the whole darn thing in Rust,

Syntax space or the they're sort of, like, comments, but you can reflect them at runtime,

probably in TypeScript 5.5.

adding types to JavaScript.

I don't really know, to be honest. Like,

Yeah. Never say never.

Mhmm. Decorators. There's 2 implementations of decorators in TypeScript. Now what happens are they ever gonna take the old

modular decorators, I can talk about those in a second.

that conflate the existing syntax and also that it doesn't block addition of new syntax in the future.

on JSR when that happens?

My my other thought Oh, that's good. Yeah. And and they just released a,

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

it turns into something at runtime, which is kind of strange. It's not how the service are. Yeah. It probably would require Yeah.

implementation of the TypeScript modules,

And I think I would ban 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 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?

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,

What was it called?

yeah, I don't know. Yeah. Maybe it'll take 10. Maybe it'll take 1. Who knows? Yeah.

slow the progress has been on, on, on Rust based type trackers, I kinda don't think so.

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

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, 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.

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

scope from GSR, and everything else gets reported from NPM. So these these 2 can really completely coexist.

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

harmony.

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 I wrote all the docs in in or sorry. I wrote it in TypeScript, But I'm curious what that looks like with JSR.

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

complete

Yeah.

JSR or NPM,

You can still get the NPM packages that are not available on JSR

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

it for me, which is is really nifty.

you say import whatever from, and then you you type j s r colon and the name of the the actual package. And

that in, or or can that be done with, like, some sort of hack? You can have it back.

whatever package to,

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, ship version. You gotta go spelunking in node modules to figure out what went wrong.

Will we eventually get

And for those, you can just install JSR packages with Npm 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?

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

on JSR exist in sort of a virtual 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, compatibility 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.

either in your home directory or in your project directory, which will tell NPM that it's importing packages from JSR.

at JSR scope on NPM.

by

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

STD underscore FS to import it in in NPM.

Yeah. So the the way it works is that,

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.

I don't know, the standard library, really, really limits how far you can

All the NPM all the existing NPM tooling just works,

Deno installs NPM packages using Npm colon specifiers. And similarly, you can install JSR packages with JSR colon specifiers.

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, Namely, you have to add explicit return types to all of your exported functions.

HTTP specifiers under the hood. It like, all the files are loaded from

proxy it over to to the NPM registry. Right? Like, at a high level? super

and and module augmentation a package was actually published by the person who claimed

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.

There's new frameworks popping up all all the time, But in our package management and package registry ecosystem, And for the tools that don't, what we'll do is we'll take the TypeScript and

so in it when JavaScript started out, we didn't really have, all these different concepts of of

things haven't really changed over the past 10 years. And I don't think for the better. Right? we set up a system where the top

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

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 So these are not all LCAS Yeah. So the way that it's it's difficult.

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

everyone registry. There's a JavaScript registry. That's where the name comes from. JSR, JavaScript And and this is really what we're aiming to do here with JSR.

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.

for any runtime that wants to use it backwards compatible with Node and NPM.

but I think what most people are are tuning ESLint to hear is, There are many type strippers out there, for for node internals.

of it,

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

Yeah.

and then we'll we'll get into, I guess, a lot more of the benefits. So, like, let's start there.

for TypeScript,

So JSR is a new JavaScript registry that we're working on built for modern JavaScript, Yeah.

That's awesome. And we're gonna go into

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

Lucas rather than 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 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.

obviously knows a lot about JavaScript and a lot has a lot of thoughts and and whatnot behind

of opinions flying on what it is. So, we have,

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.

Sanity on today, who is a software engineer at Deno. Deno JS the folks behind JSR,

give us a little bit more info.

Pretty excited to talk about it. A lot

You wanna give us a a quick rundown of I know I I I gave a little intro, but,

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

like, there's been the addition of the files tab, 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,

That is a great question. So Npm hasn't really evolved in the past 10 years. Right? It's maybe it's not such a super well known feature, but it's it's useful for sort of supply chain security, 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 incredibly cheap to operate.

And we wouldn't be able to do those if we had to support, 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.

Yes.

And we do a lot of static analysis on the source code we upload because we provide things like documentation generation For Want this to be something that is really driven by JavaScript,

CommonJS in in addition to ESM.

explicit?

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