JSR - JavaScript package साझा करने के लिए एक नई registry
- पिछले कुछ वर्षों में yarn और pnpm जैसे नए package manager आए हैं और उन्होंने package डाउनलोड करने के तरीके को बेहतर बनाया है
- लेकिन JavaScript ecosystem का मूल npm package registry लगभग विकसित ही नहीं हुआ है
- आखिरी उल्लेखनीय अपडेट कई साल पहले जोड़ा गया "files" टैब था
- विडंबना यह है कि तेज़ी से विकसित होने वाली JavaScript language एक पुराने distribution model से बंधी हुई दिखती है
JavaScript module system की समस्याएँ
- जब Node बनाया गया था, तब JavaScript के लिए कोई standard module system नहीं था, इसलिए npm registry और Node ने मूल रूप से खामी वाले CommonJS(
require) सिस्टम को डिफ़ॉल्ट के रूप में अपनाया
- यह ऐसा सिस्टम था जो browser में काम नहीं करता था
- लगभग 10 साल पहले, 2015 में, language ने खुद ES module(
import) syntax को अपनाया
- आज अधिकांश JavaScript, ES module का उपयोग करके लिखी जाती है, लेकिन इन modules को distribute करने का रास्ता अब भी जटिल है
- खासकर जब TypeScript शामिल हो
- ecosystem में इसी स्पष्ट कमी के कारण JSR का जन्म हुआ
- JSR कोई और package manager नहीं है, बल्कि server-side runtime, browser और विभिन्न tools में JavaScript और TypeScript साझा करने के तरीके को बदलने के लिए डिज़ाइन की गई एक परिवर्तनकारी registry है
JSR की विशेषताएँ और फायदे
- JSR लंबे समय से developers को परेशान कर रही जटिलताओं को सरल बनाकर code distribution process को मूल रूप से बेहतर बनाता है
- ESM-only और TypeScript-first JSR,
package.json configuration और भूलभुलैया जैसे tsconfig compiler options के असहज संतुलन की ज़रूरत को हटा देता है
- package scoring system के ज़रिए JSR code distribution की best practices को प्रोत्साहित करता है
- Dart community के pub.dev की तरह, यह उन packages को अधिक score देता है जिनमें export किए गए हर symbol के लिए व्यापक JSDoc documentation शामिल हो
- Go और Rust जैसे अन्य आधुनिक programming ecosystems की तरह, JSR डिफ़ॉल्ट रूप से automatic documentation generation प्रदान करता है
npm के साथ संबंध
- JSR एक registry है, npm registry के लिए कोई और client नहीं
- लेकिन इसका मतलब यह नहीं कि npm की हर चीज़ को छोड़ देना होगा या एक अलग-थलग JavaScript module ecosystem में जाना होगा
- JSR को npm registry का पूरक बनने के लिए डिज़ाइन किया गया है, npm को बदलने के लिए नहीं
- JSR packages, npm packages पर depend कर सकते हैं (उदाहरण: this package referenc e)
- इसके अलावा JSR packages को मौजूदा npm-केंद्रित software में भी इस्तेमाल किया जा सकता है
- क्योंकि JSR खुद npm-compatible tarball वितरित करने वाली npm registry की तरह काम करता है, जिसे npm.jsr.io पर access किया जा सकता है
- इससे JSR packages को npm, yarn या pnpm इस्तेमाल करने वाले किसी भी software में शामिल किया जा सकता है और private registries के साथ integrate किया जा सकता है
- JSR द्वारा वितरित npm tarball optimize किए गए होते हैं
security पर ज़ोर
- Deno में JavaScript development में security को सर्वोच्च प्राथमिकता दी जाती है
- कोई भी registry प्रकाशित किए गए सभी code की पूरी निगरानी नहीं कर सकती, लेकिन JSR publisher transparency देता है और publishing process को सुरक्षित करता है
- GitHub Actions और OIDC token को integrate करके, JSR software artifacts के लिए supply chain levels का उपयोग करते हुए उन्नत, verify किए जा सकने वाले provenance proofs बनाता है और उन्हें Sigstore में संग्रहित करता है
- इससे न केवल code की प्रामाणिकता सुनिश्चित होती है, बल्कि developers जो लागू कर रहे हैं उसके प्रति भरोसा और जवाबदेही भी स्थापित होती है
JavaScript development का केंद्र
- JavaScript कई programmers की साझा language होने के कारण सार्वभौमिक और बेहद सुलभ है
- इस language को एक ऐसे केंद्रीय hub, यानी town square की ज़रूरत है, जहाँ developers बिना अनावश्यक जटिलता के अपना काम साझा कर सकें
- हमारा मानना है कि JavaScript आने वाले लंबे समय तक software development के केंद्र में रहेगी, और JSR का लक्ष्य इसी निरंतर प्रासंगिकता को समर्थन देना है
- JSR ecosystem का सिर्फ एक और टूल नहीं है, बल्कि यह JavaScript और TypeScript distribution के बारे में हमारी सोच में एक बुनियादी बदलाव को दर्शाता है
3 टिप्पणियां
लगता है jsr को npm से डाउनलोड किया जा सकता था,, lol
php बर्बाद हो जाए
JS लेख में PHP क्यों?? PHP प्रोजेक्ट पर काम कर रहे इंसान के तौर पर दिल पर लगती है।