JSR: 자바스크립트 패키지 배포 및 소비의 현대화

JSR(JavaScript 레지스트리)은 개발자 경험을 개선하기 위해 TypeScript 우선 코드 및 ECMAScript 모듈을 위해 설계된 새로운 모듈 레지스트리입니다.

### JSR 소개: 자바스크립트 패키지 레지스트리의 미래
* 📦 자바스크립트는 웹 인프라에 매우 중요하며, **JSR은 네이티브 타입스크립트를 지원하는 새로운 모듈 레지스트리**로 도입되었습니다.
* 🌐 JSR은 **npm과 함께 작동**하도록 설계되었으며 여러 런타임을 지원하며 **퍼블리셔와 소비자 모두의 개발자 경험을 개선**하는 것을 목표로 합니다.
* 🔒 **보안을 우선시**하고, **자동 생성 문서**를 제공하며, **패키지 게시 모범 사례**를 권장합니다.
* 🚀 사용자는 **Dino, Node 및 기타 런타임에서 JSR 패키지를 쉽게 사용**할 수 있으며, 커뮤니티 관리를 통해 **자바스크립트 생태계를 향상**시키는 것을 목표로 합니다.

hello how's it going everybody the schedules are a little bit confusing here. Uh I wasn't exactly sure what time I was talking but um I've got uh something new to talk about today. Um it's called JSR um uh and I think it's uh good to reflect on the importance of JavaScript in the world. JavaScript is not just another programming language. The web is hosting all sorts of infrastructure right your your bank your Metro Services uh the entire world is sitting on top of web technology and because of that I think it's pretty clear that HTML and CSS are not going to go away in the next 5 years or even 10 years maybe even longer than that. Uh the world is is really sitting on top of web browsers in in a pretty serious way and JavaScript is part of the standards that make up uh the web because of that uh JavaScript is in some ways the default programming language. Uh it is the default scripting language. Uh it is the easiest way to express business logic it's not the solution for every task if you're

building a database. Don't use JavaScript. That's a bad idea, right? If you're building an operating system like these are, these are tasks for another language. But for kind of the everyday, let's call it business logic, JavaScript is, is, is, and I think will continue to be where, uh, the focus is, uh, and the place that we share JavaScript is in npm. This has, arguably, the is the most successful software repository registry, uh, in the history of, of computers. Um, there are over 2 million packages hosted at npm, and it is, um, you know what, what makes node what it is today. Uh, we, we collectively here have built this thing. Uh, I mean, Isaac specifically has built this thing, but, uh, uh, we collectively have all uploaded packages and, uh, made this, uh, a really useful resource for moving quickly in software. But npm is showing its age, as is node, and Publishing JavaScript packages in 2024 is difficult, right? You have these most people are programming these days in TypeScript, and so you have this whole problem of transpiling your

your typescript and getting DTS files out of it you have to wrestle with export conditions. Uh, you have to figure out navigate your way through through commonjs and and esm. Uh, should you be publ you're you're most people are writing in esm these days, but do you publish in esm? Do you publish in common JS? How exactly do you do that? Do you publish in both? Uh, this is all becoming relative difficult to understand, increasingly difficult to understand. Um, go to definition, for example, doesn't work in typescript, right? You you you most people are not publishing the the code that they write, and so when you are linking to a package and and try to examine the source code, you might get some minified JavaScript, uh, uh, if you're unlucky, unlucky, but you definitely you know even if you get some nice JavaScript, uh, it's it's definitely not the original typescript source code. Um, npm packages are big, uh, you're you're downloading whole T balls, and uh, most packages have some implicit uh assumptions about a no. JS.

environment, and I don't think we really have to deal with all of this. It doesn't have to be this way. So JSR is a new module registry. I am announcing it right now, and online as of this morning. Thanks. So I've got quite a bit of time here, so hopefully I'll get a chance to do a demo, and hopefully it won't break. We'll see. But JavaScript stands for JavaScript registry. It is obviously a place where you can publish JavaScript, but it does have native TypeScript support, and you are encouraged to publish the code that you write, i.e., your TypeScript code. It is ECMAScript modules only. It is designed to work with npm and not against it. npm has very strong network effects, right? It's hard to do something different because everything depends on something inside of npm. You have too much functionality there. This is

explicitly designed to work with multiple run times. In 2024, we have a number of them, right? We've got Node, we've got Deno, we've got Bunn, we've got Cloudflare workers, and yeah, it's time to share code and make it explicit which run times are for which code. And npm, you know, post GitHub acquisition, I think has not moved too much, and I think, you know, it's time to have some better developer experience for both publishers and for consumers. So I mentioned it works with npm and not against it. So TypeScript is a superset of JavaScript, right? This is kind of how you should think of JSR. JSR is a superset of npm packages. In JSR, can depend on npm packages. It's not illegal in any way to use npm packages. It's just an overlay on top of that where you can publish TypeScript-first code, ESM-first code. So just a bit about why here npm.

was built a long time ago, you know, 14 years ago now. Uh, and JavaScript is very different today. Uh, TypeScript and ESM are the new standard, and we think that a modern registry should be designed for those things. And, uh, I think it is well past the time that we move beyond CommonJS. Uh, npm packages. It's hard to distribute code on npm. You, it requires the authors of the package to do so much work. You have to figure out all of this transpilation nonsense. You have to figure out the ESM, the ECMAScript modules in CommonJS situation. Uh, you don't get documentation, which is pretty substandard for the world's most popular programming language. Um, if you are publishing code in Rust or Go or essentially any other programming language, you get autogenerated docs out of the box. Um, yeah. Um, as I mentioned, TypeScript is a first-class citizen, so you can publish and consume TypeScript as is. But, uh, you don't need to leave everybody behind.

uh, if your users are not using TypeScript, they can still use your module. JSR takes care of the distribution part of the equation, as Registry should. So, you can, yeah, it handles kind of the doc generation, the DTs files, and to a large extent, the cross-runtime compatibility story. Yeah, I, so for consumers of, we can do a much better job for publishing packages. But I think what everybody cares about is how easy it is to consume these things. And with JSR, we believe we've improved the situation quite a bit with autogenerated documentation, kind of a package scoring system to encourage people to use best practices, runtime compatibility labels to be able to tell your users pretty clearly which runtime this software is for, and because you're publishing the code that you write better auditability. And yeah, all of this that kind of works into existing workflows, which I can demo in a second. Publishing is great, no transpilation, no CommonJS.

just published sources. It is simple and secure and really encourages you to write TypeScript directly. I mean, how many people have wrestled with TSC or compiler options and are a little unclear about which options they need to choose. JSR lets you know what you should do for writing TypeScript. I mentioned security, so you don't use tokens to provision to publish JSR packages. JSR requires a GitHub login and requires kind of an explicit approval for every publishing flow, unless you're doing it from GitHub actions, in which we can give you a really nice experience with OpenID Connect authentication, and in particular being able to give kind of cryptographic proof via Sigstore that your GitHub user has run these commands to produce this package. These things become. There's been a lot of security problems with npm, and this is totally a solvable problem, and with these security constraints, I think we can safely put behind the

days where you are uh installing completely untrusted unknown software from random people on the internet and putting you know real real things at risk um we want this to be a moderated system so this is something that we are building as a public service for the JavaScript community and uh in order to be maximally useful uh we have established certain rules for uh contributing and participating in jsr so for one all packages have to be within a scope there's no top level packages no fighting over over names um there's quotas for the number of Scopes so that people don't just go run away and grab a bunch of names and in particular we have a no scope squatting policy so if you are doing something terrible like you know grabbing the at Google scope uh then uh we'll just take it away from you um but by the way we we you can't grab the at Google scope because we've also provisioned uh very wellknown names of of projects and companies and stuff and

kind of set set those aside uh but you know for those that you know the at KLM scope uh uh I I think we probably haven't covered yet and if somebody goes and grabs that that doesn't work at km well well we we can correct that situation right it is not a hands-off uh Wild West sort of situation this is for programmers this is a public service and is meant to be maximally useful to people um this is also open source MIT licensed and uh it is not intended for monetization um uh the GitHub repo is here you can you can check it out um and it it's it's really designed to be run on commodity cloud services uh and and designed to be run very cheaply uh it's it's essentially a CDN in front of S3 um as as cheap as it gets essentially in in terms of uh serving packages um yeah it is uh you know I have a company uh dinoland and uh we of course have have developed this and are paying for

the bills at the moment, but we aim to somehow make this community moderated and managed over time, right? It is meant to be a public service. It's just we have to find the right people to, you know, who can kind of usher that in. And now it's time for the scary part. So let's see if this works. So, number one problem, do I have internet? Yes, I do. Okay, so what I'm going to do is create a normal npm library and, yeah, let's kind of go from there. So, I really get annoyed by, I'm American, of course, and I really get annoyed by the date system in the US. Everybody's writing month/day, and it's just like, please, people, don't do that. And you come to Europe, and they do the day/month, or I can't even remember who or whose anymore. And gosh, I kind of think the temporal library has actually made this worse.

because it encourages people to uh kind of use location-specific uh uh date formatting. I am strongly against that. I there is there is one true way of formatting a date um and let's write a library to do that. Um so one true date and let me go in there and open up VSS code and let me know if uh this is visible enough or is not visible in particular. Let me create a package Json file and we want to be modern developers, right. So so let's let's do type module to uh to get this uh to be a commonjs library. Let me open up the terminal or let me let me create another file here. We're going to do an index.ts file, a typescript file and uh in this file we are going to uh export a function, uh one true date that is going to take a date and is going to return a string and it's going to do something. Um and gosh I I the the only library that I know that can format dates properly uh is is this

uh date FNS uh uh project so uh I'm going to actually uh mpm install npm add uh date FNS that seems to be added to my package Json yes so I can import this import uh date FN and maybe I'm going to pull in this format function oops format function from date fens and this format function lets you lets you kind of properly format dates here so I can uh return format and it takes a date and then a format string so I'll do year year year month month Day Day and okay that's this this is the right way to format dates by the way um please do not format dates any other way around me it's it's uh it's like very painful um okay so now I've got this typescript file um and I want to run it obviously I can use Dino of course like that's great but I'm trying to give you the node experience which is uh uh not great uh so so we have to run TSC right we have to like compile this to JS so I'm just

going to naively here try to run TSC, and I get a bunch of errors as you always do, and you're like, oh God, all right, now what? Um, well, it did actually output some JavaScript, but by default this is CommonJS JavaScript, and we're trying to move forward. We are trying to get into the future of ESM. Um, and you can actually achieve this by doing `module: node next` with TSC, and then suddenly, uh, TSC has properly stripped my code, and I have normal ESM JavaScript. And just to make sure this is working properly, let me start up node and import `/index.js`, and let me await it a little dynamic await. It seems to have worked. Underscore one true date and new date. Okay, seems to have worked. It is March 1st. Okay, um, so this is kind of what you would need to go in the past to publish to npm. You would need to set up some sort of build process, and then you publish those JS files, and you know.

you probably don't want to do it as just ESM because then nobody's going to be able to use them. Like or maybe like who knows. Uh, you probably also need CommonJS. It's going to be a big curfuffle and you're going to spend like a day doing this. Um, and I'm going to just remove this index JS because we don't need that crap. Um, we are going to publish this to JSR. So let me open up JSR doio. And yeah, this is the scary part of the demo because this is literally a live demo. Um, and let me go to publish a package here. So what I do first is I choose a scope. I'll choose my Ry scope. And then I can choose a package name, one true date. And I can create that package. Okay, and that gives me some instructions on how to publish this. So it says, okay, well, you got to drop this into your JSR JSON. Uh, some some kind of configuration about the name and and version and exports. So let me do

that so I come back over here, and I'm going to add another file jsr Json. Let me copy in this data into here, and then it says, Okay, now you can run npm npx jsr publish. You can also do it with doo much better with Dino, of course, of course, but I'm trying to give you the poor man's view of the world. So, let me just run npx jsr publish, and I get an error. Damn it. Oh no, that's okay because this mod. TS is not index TS. So, let me just change that, and let me run that command again. Seems to be working. So now I have to kind of manually approve this because I'm logged into the website with my GitHub account. So, I click approve, and it's uploading the tarball. And now I have this kind of package page for my one true date package. And you know, well, we can explore these things a little bit more, but I think what's interesting here

is is we got our our kind of symbol export our our one true date, and if I click on that um, I've got uh some ways to import it from different from different runtimes, uh, and I've got some some autogenerated documentation. It takes a date, returns a string, uh, I'm noting that that I forgot to put in some uh JS stock in into this, so let me let me actually go back to uh to this and do the proper way to format a date, um, and save that. And now I I'm going to upload a new version of this, so and this is not an API change, just a patch release, so let me bump the version there and just run this command again. Hopefully this works, okay, so now we can check out this one true date function again, and yes, now it it has extracted that that JS stock properly, okay, great, so let's let's kind of explore using this package in in different ways, so you know now I've published my my package, you know let's pretend I'm a dino user, so let me just

uh dino in it doot test uh and CD into my doo test project so this is this is a new now I'm kind of the the user of of this package and um you know Dino if you're not familiar with it is is like J like like no just just uh much cleaner um and uh uh well what I'm going to do here is uh just follow the instructions so on the dino tab it has uh dino add ry1 true dates let me copy that and let me watch this Dino Json file just for a second so as I run this um it's actually inserted this Imports statement in into here so you know Dino is is pretty uh pretty adamant about adhering to web standards and and this is actually an import map uh and it's it's mapping the the specifier at ry1 true date to this jsr colon Ry blah blah blah blah blah uh you can essentially ignore that because uh in your main file let me delete this kind of AD function

that the init script created. Um, I can just write in this, uh, one true date. Uh, this import statement here, um, and, uh, good, the squiggly lines went away. Um, and I'm getting an error that's never read, that's okay. Uh, so let's just try to use this one true date new date, put us oh, uh, oh, okay. All right. And we'll to do run main.ts, and it's outputted the correct state, thankfully. So now I've consumed this module from Dino. Let me just, uh, hover over this. So I am getting kind of the proper, uh, JS stock here, and let me go to definition on this guy. And when I do that, I end up not in a transpile Javascript file, but actually in the original typescript source code, uh, and this is very important, right? You, when you're interacting with libraries, you want to see the code that you are very likely going to be debugging something in some dependency you have, and you want to get to the code that

they have distributed as soon as possible. Um, that all works with Dino. So, of course, it works with Dino. But you're, you're, you maybe are not yet a Doo user. Um, and maybe you are a Vit user, let's say. Um, so, so let's do npm create V and do a little V test, right? So, this will all run with Node, of course, and I'll choose vanilla. I'll choose TypeScript. I'll go into my V test, and let me open up VS Code again. And so now I, I've got my little V project here that's, you know, got some stuff in the package JSON. Um, let me, well, first of all, let me just start up the dev server and make sure this is running. So, npm run dev. Uh, oh, V not found. npm i. And now we wait. How are you all morning's going? Enjoying the conference? Okay. All right, we're done. Okay. Uh, so now we can run the dev server, and let me make sure I can get to

the templated screen is great. So now let's say that we want to use this one true date in our V project, right? So we go back over to JSR, and we click on npm, and it gives me this little npx jsr add command. So let me copy that and paste it over. Let me start another terminal, run this, and you might see that this package.json got updated. Node does not use import Maps. Node uses package.json imports. And if I look in this node modules folder, you will see some stuff in here. You will see the one true date in the node modules folder. I'm not going to dive too deeply into that. I think what's important though is that we can now import this like we can any other package from npm. And let me go into the main TS file and copy in this import statement here. And I believe it's squiggly because it's never read.

fine, uh, so let me try to call this in the H1 here. So, uh, one true date, new date, end bracket. And let me go over to my V server. HMR should work, and sure enough, we have now used this function from a node project from V in particular. Um, so, uh, hopefully that gives you a sense of kind of the usability of this. It just works with your existing software, and you get a bunch of stuff for free from this. Um, it also encourages you to be a better programmer. So, this one true date, if you click this little score button here, has, um, you know, I have not done a very good job, uh, uh, writing this module. It is, you know, it was good for a demo, but it's definitely not ready for the prime time. And what JSR does is kind of recommends ways to improve this, add more documentation, add a readme, best practices, pushes you, pushes the, the, the universe of JSR packages to be better. Um, yeah, uh, so thankfully that worked.

yeah, so uh, like I said, this is now open. This is at JSR Doio. We've been working on this for a while now, um, and it is early days. We are looking for feedback on this. Um, so, uh, yeah, if you have any, please, please let us know. And, uh, yeah, I would just say, you know, we need to level up the JavaScript ecosystem, right? And my hope is that with this, and, you know, maybe work built on top of it, that we can achieve that and really have a better future for the default programming language. Because the default programming language is going to be here for a while. Like, I think it's going to be here indefinitely. Um, as I said, we're interested in having Community moderators, um, and I've got a link up here if that interests you. Um, and, uh, yeah, there's some other links here, including my email address if you have some feedback.

Um, and yeah, that's all I got for you. [Applause]

Ryan Dahl introduces JSR at DevWorld 2024

This is the official Deno YouTube channel, where we'll share talks, product updates, and other resources.

Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.

Website: https://deno.land
GitHub: https://github.com/denoland
Discord: https://discord.com/invite/deno
Twitter: https://twitter.com/deno_land
Newsletter: https://deno.news


Deno

자바스크립트의 중요성과 JSR의 도입

JavaScript는 비즈니스 로직을 표현하는 기본 스크립팅 언어이자 웹 표준의 핵심 역할을 하는 웹 기술에서 중요한 역할을 담당하고 있습니다.

2백만 개 이상의 패키지를 호스팅하는 npm 레지스트리는 소프트웨어 개발을 위한 중요한 리소스였지만 TypeScript의 부상과 복잡한 퍼블리싱 프로세스로 인해 어려움에 직면해 있습니다.

JSR(JavaScript 레지스트리)은 네이티브 TypeScript를 지원하는 새로운 모듈 레지스트리로, ECMAScript 모듈에 초점을 맞추고 npm의 기능을 보완하기 위해 도입되었습니다.

JSR은 퍼블리셔와 소비자 모두에게 더 나은 개발자 경험을 제공하기 위해 Node, Deno, Bunn 및 Cloudflare 워커를 포함한 여러 런타임에서 작동하도록 설계되었습니다.

TypeScript 및 ESM 우선 코드를 위한 최신 레지스트리를 제공하여 문서화, 패키지 채점 및 런타임 호환성 레이블을 개선합니다.

또한 JSR은 게시 흐름에 대해 GitHub 로그인 및 명시적 승인을 요구하여 보안을 강화하여 npm과 관련된 보안 문제를 해결합니다.

자바스크립트 커뮤니티를 위한 중재 시스템 구축

이 프로젝트는 신뢰할 수 없는 소프트웨어 설치의 안전을 보장하기 위해 자바스크립트 커뮤니티를 위한 중재 시스템을 만드는 것을 목표로 합니다.

모든 패키지가 일정 범위 내에 있어야 한다는 요건과 이름 사재기를 방지하기 위한 할당량 구현 등 기여에 대한 규칙을 마련했습니다.

이 시스템은 오픈 소스이며, MIT 라이선스를 받았으며, 수익 창출을 목적으로 하지 않고, 패키지를 저렴하게 제공하기 위해 상용 클라우드 서비스에서 실행되도록 설계되었습니다.

JSPM에 자바스크립트 패키지 설정 및 게시하기

JavaScript 패키지를 설정하는 과정에는 필요한 종속성을 설치하고 TSC를 사용하여 코드를 ESM JavaScript로 컴파일하는 과정이 포함됩니다.

ESM의 향후 버전으로의 전환은 "module: node next"로 TSC를 구성하여 수행할 수 있습니다.

JSPM에 패키지를 게시하려면 jsr.

json 파일에 구성을 추가하고 "npx jsr publish"를 실행한 다음 웹사이트에서 수동으로 승인해야 합니다.

디노 및 노드와 함께 원 트루 데이트 패키지 사용

가져오기 웹 표준에 따라 Dino 환경에서 원 트루 데이트 패키지를 가져와서 사용하는 방법을 보여줍니다.

그런 다음 Vite 프로젝트를 생성하고 개발 서버를 실행하여 노드 환경에서 패키지를 사용하는 과정을 보여줍니다.

Dino에서 원 트루 데이트 패키지를 사용할 때 원본 타입스크립트 소스 코드에 원활하게 액세스할 수 있는 환경을 강조합니다.

V에서 노드 프로젝트의 원 트루 날짜 사용

npm 패키지 관리자와 npx jsr add 명령을 사용하여 V 프로젝트에 하나의 실제 날짜를 쉽게 추가할 수 있습니다.

원 트루 데이트를 다른 npm 패키지와 마찬가지로 V 프로젝트에서 가져와서 사용할 수 있으므로 기존 소프트웨어에 추가 기능을 제공할 수 있습니다.

JSR은 V에서 노드 프로젝트의 사용을 허용할 뿐만 아니라 JSR 에코시스템의 패키지 품질 향상을 위한 권장 사항을 제공하고 장려합니다.