JSR: JavaScript रजिस्ट्री

मूल लेख ↗ Hacker News चर्चा ↗

JSR नाम की एक नई JavaScript package registry, जिसे Deno टीम ने बनाया है, TypeScript‑first, ESM‑only विकल्प के रूप में npm का विकल्प देने का लक्ष्य रखती है, जबकि मौजूदा npm packages और tooling के साथ interoperable बनी रहती है। समर्थक built-in type handling, automatic docs, provenance, और modern runtimes के साथ बेहतर integration को aging, Microsoft‑controlled npm registry पर इसके प्रमुख लाभ बताते हैं। आलोचक एक और central registry की आवश्यकता पर सवाल उठाते हैं, ecosystem fragmentation, naming और governance मुद्दों को लेकर चिंतित हैं, और formal standard के अभाव में TypeScript पर भारी निर्भरता तथा heavy type inference को penalize करने जैसे design choices पर चिंता व्यक्त करते हैं.

JSR का उद्देश्य और डिज़ाइन

  • JavaScript/TypeScript के लिए एक नई केंद्रीकृत रजिस्ट्री, जिसे Deno टीम ने बनाया है लेकिन जो runtime-agnostic होने के लिए बनाई गई है।
  • Deno में URL-आधारित imports की समस्याओं से प्रेरित: duplicate dependencies (semver-आधारित deduping नहीं) और नाज़ुक URLs जो गायब हो सकते हैं।
  • TypeScript और ESM पर केंद्रित: आप TS source publish करते हैं और JSR transpilation, .d.ts generation, docs, और cross-runtime builds संभालता है।
  • Deno में HTTPS imports अभी भी समर्थित हैं, लेकिन JSR को अधिक मजबूत default के रूप में रखा गया है।

TypeScript, केवल Syntax वाला दृष्टिकोण, और “Slow Types”

  • रजिस्ट्री TypeScript syntax पर निर्भर करती है, पूरे type system पर नहीं; TSC-आधारित analysis नहीं है।
  • type operations को तेज़ और स्थिर रखने के लिए, यह स्पष्ट public API types को मज़बूती से प्रोत्साहित करती है और inference को सीमित करती है (“slow types” को कम score मिलता है, लेकिन वे फिर भी publish हो सकते हैं)।
  • आने वाले TS options जैसे isolatedDeclarations और editor quick-fixes को इस friction को कम करने वाला बताया गया है।

npm और Tooling के साथ संबंध

  • JSR एक registry है, package manager नहीं; यह npm-style APIs और node_modules के ज़रिए मौजूदा tools के साथ integrate करता है।
  • JSR modules npm modules पर निर्भर हो सकते हैं और इसके उलट भी; Node के लिए JS + .d.ts emit करने वाली एक npm compatibility layer है।
  • “npm का superset” जैसे marketing language को लेकर कुछ भ्रम है; कई commenters “additive” या “complementary” जैसे स्पष्ट शब्द सुझाते हैं।
  • मौजूदा Deno-to-npm workflows (जैसे dnt) अभी भी अल्पकाल में उपयोगी हैं; लंबे समय में JSR का लक्ष्य उस use case को सीधे कवर करना है।

Governance, Namespaces, और Immutable व्यवहार

  • Scopes curated हैं; स्पष्ट brand scopes को verified owners को reassigned किया जा सकता है।
  • पुराने versions अपरिवर्तनीय रहते हैं और उपलब्ध रहते हैं; नया scope owner उसी scope के तहत नए versions publish कर सकता है।
  • कुछ लोगों को यह पुरानी registry naming समस्याओं की पुनरावृत्ति लगता है; अन्य लोग collisions से बचने के लिए DNS- या URN-based naming का प्रस्ताव देते हैं।

Runtime, Browser, और WASM उपयोग

  • Deno, Node, Bun के साथ काम करता है; Node एक compatibility layer का उपयोग करता है।
  • Browser usage अभी first-class नहीं है; JSR packages के HTTP/ESM imports के लिए esm.sh जैसी external services का उल्लेख किया गया है।
  • source-phase imports proposal के माध्यम से WASM source imports के लिए planned support है।

प्रतिक्रिया और आलोचनाएँ

  • उत्साह: बेहतर TS support, auto-docs, provenance, Microsoft-नियंत्रित npm का विकल्प, open source implementation।
  • संदेह: एक और registry जोड़ता है और fragmentation का एहसास देता है; कुछ लोग मानते हैं कि ये सुविधाएँ बेहतर npm-side tooling से हल की जा सकती हैं।
  • TS पर अत्यधिक निर्भरता, अतिरिक्त build “magic,” semver व्यवहार, और marketing (नाम “JSR,” TS focus बनाम “JavaScript” branding, AI-जैसी landing pages) को लेकर चिंताएँ।