JSR - 자바스크립트 패키지 공유를 위한 새로운 레지스트리
- 지난 몇 년 동안 yarn이나 pnpm 같은 새로운 패키지 매니저가 등장하며 패키지 다운로드 방식을 개선해 왔음
- 하지만 자바스크립트 생태계의 핵심인 npm 패키지 레지스트리는 거의 진화하지 않았음
- 마지막 주목할 만한 업데이트는 수년 전에 추가된 "files" 탭이었음
- 활발히 진화하는 것으로 알려진 자바스크립트 언어가 역설적이게도 시대에 뒤떨어진 배포 모델에 발목 잡혀 있는 것처럼 보임
자바스크립트 모듈 시스템의 문제점
- Node를 만들 당시에는 자바스크립트용 표준 모듈 시스템이 없었기에, npm 레지스트리와 Node는 근본적인 결함이 있는 CommonJS(
require) 시스템을 기본으로 채택했음
- 이는 브라우저에서는 작동하지 않는 시스템이었음
- 거의 10년 전인 2015년에 언어 자체적으로 ES 모듈(
import) 문법을 채택함
- 오늘날 대부분의 자바스크립트는 ES 모듈을 사용해 작성되지만, 이러한 모듈을 배포하는 경로는 여전히 복잡함
- 특히 TypeScript가 관련된 경우 더욱 그러함
- 이러한 생태계의 명백한 격차로 인해 JSR이 탄생하게 됨
- JSR은 또 다른 패키지 매니저가 아니라 서버 사이드 런타임, 브라우저, 다양한 도구에서 자바스크립트와 타입스크립트를 공유하는 방식을 혁신하기 위해 설계된 변혁적인 레지스트리임
JSR의 특징과 이점
- JSR은 오랫동안 개발자들을 괴롭혔던 복잡성을 간소화함으로써 코드 배포 프로세스를 근본적으로 개선함
- ESM 전용이고 TypeScript 우선인 JSR은
package.json 설정과 미궁 같은 tsconfig 컴파일러 옵션의 불편한 조정을 제거함
- 패키지 스코어링 시스템을 통해 JSR은 코드 배포의 모범 사례를 장려함
- Dart 커뮤니티의 pub.dev와 유사하게, 내보내는 각 심볼에 대한 포괄적인 JSDoc 문서를 포함하는 패키지에 더 높은 점수를 부여함
- Go나 Rust 같은 다른 최신 프로그래밍 생태계에서 볼 수 있듯이, JSR은 기본적으로 자동 문서 생성 기능을 제공함
npm과의 관계
- JSR은 레지스트리이지, npm 레지스트리용 또 다른 클라이언트가 아님
- 하지만 이는 npm의 모든 것을 포기하거나 분리된 자바스크립트 모듈 생태계로 전환해야 한다는 의미는 아님
- JSR은 npm 레지스트리를 보완하도록 설계되었지 npm을 대체하려는 것이 아님
- JSR 패키지는 npm 패키지에 의존할 수 있음 (예: 이 패키지 참조)
- 또한 JSR 패키지는 기존의 npm 중심 소프트웨어에서 사용될 수 있음
- JSR 자체가 npm 호환 tarball을 배포하는 npm 레지스트리(npm.jsr.io에서 접근 가능)로 작동하기 때문
- 이를 통해 JSR 패키지를 npm, yarn 또는 pnpm을 사용하는 모든 소프트웨어에 포함하고 프라이빗 레지스트리와 통합할 수 있음
- JSR이 배포하는 npm tarball은 최적화되어 있음
보안 중시
- Deno에서는 자바스크립트 개발에서 보안을 최우선 과제로 삼음
- 어떤 레지스트리도 게시된 모든 코드를 포괄적으로 감시할 수는 없지만, JSR은 발행자에 대한 투명성을 제공하고 발행 프로세스를 보호함
- GitHub Actions와 OIDC 토큰을 통합함으로써 JSR은 소프트웨어 아티팩트를 위한 공급망 수준을 사용하여 고급의 검증 가능한 출처 증명을 생성하고 이를 Sigstore에 저장함
- 이는 코드의 진위를 보장할 뿐만 아니라 개발자가 구현하는 내용에 대한 신뢰와 책임을 확립함
자바스크립트 개발의 중심지
- 자바스크립트는 많은 프로그래머의 공통 언어로 보편적이고 접근성이 뛰어남
- 이 언어는 개발자들이 불필요한 복잡성 없이 작업물을 공유할 수 있는 중앙 허브, 즉 타운스퀘어가 필요함
- 우리는 자바스크립트가 앞으로 많은 세월 동안 소프트웨어 개발의 중심이 될 것이라 믿으며, JSR은 이러한 지속적인 연관성을 지원하는 것을 목표로 함
- JSR은 단순히 생태계의 또 다른 도구가 아니라 우리가 자바스크립트와 타입스크립트 배포에 대해 생각하는 방식의 근본적인 변화를 나타냄