The Everything NPM Package
एक experimental “everything” npm package, जो tens of thousands of अन्य packages पर निर्भर था, ने npm की unpublishing policy में एक खामी उजागर की, जिससे maintainers के लिए अपने packages हटाना व्यावहारिक रूप से रुक गया यदि कोई भी पैकेज wildcard version के जरिए उन पर निर्भर हो। टिप्पणीकार इस पर बहस करते हैं कि कितना दोष package author का है और कितना npm के design choices का, खासकर `*` versions के handling और left-pad incident के legacy reaction को लेकर। यह घटना JavaScript की micro-dependency culture, कमजोर standard library, और semantic versioning पर भरोसे को लेकर व्यापक चिंताओं को भी फिर से उठाती है, और Go, Rust, Maven जैसे ecosystems से तुलना, साथ ही vendoring, बेहतर tooling, और dependencies के आसपास सख्त norms जैसे सुझाव सामने लाती है.
NPM “*” Versioning and Unpublish Policy
- “*” निर्भरता बाध्यता और npm के unpublish नियमों का मतलब है कि “everything” पर निर्भर एक अकेला पैकेज व्यावहारिक रूप से लेखकों को अपने ही पैकेज unpublish करने से रोक सकता है।
- कुछ लोग इसे “bug” कहते हैं; अन्य कहते हैं कि यह versions के गायब होने पर builds को टूटने से बचाने के लिए जानबूझकर किया गया है।
- सुझाव:
*की “नरम” व्याख्या, ताकि कम से कम एक version मौजूद रहने तक unpublish की अनुमति हो।- Soft deletes / yanking: नए resolution के लिए versions को छिपाना, लेकिन existing lockfiles के लिए उन्हें फिर भी serve करना।
- unpublish requests के लिए manual review या malware/legal मामलों को छोड़कर unpublish को पूरी तरह अस्वीकार करना।
SemVer, Pinning, and Reliability
- JS ecosystem में SemVer कितना भरोसेमंद है, इस पर बहस:
- कुछ लोग अक्सर होने वाली accidental breaking changes देखते हैं और मानते हैं कि SemVer लगभग अर्थहीन है।
- अन्य बताते हैं कि अधिकांश minor/patch updates ठीक काम करते हैं; breakages दुर्लभ हैं और उन्हें bugs माना जाता है।
- सामान्य mitigation: exact versions pin करना और manually update करना, SemVer को केवल review intensity के संकेत के रूप में उपयोग करते हुए।
- Pinning तब मदद नहीं करता जब कोई version unpublished हो जाए, इसलिए unpublish नियमों को लेकर विवाद है।
Responsibility for the “Everything” Package
- विचार “irresponsible experiment/trolling” से लेकर “वैध stress test जिसने npm design की खामी उजागर की” तक फैले हैं।
- कई लोगों का तर्क है कि मूल समस्या npm की policy है, experiment नहीं; कुछ मानते हैं कि author को अधिक विस्तृत explanation देनी चाहिए, जबकि अन्य को किसी बड़े apology की आवश्यकता नहीं लगती।
Micro‑Packages, Culture, and Risk
- व्यापक आलोचना: अत्यधिक micro-dependencies और trivial packages पर जरूरत से ज्यादा निर्भरता, जो breakage और security risk बढ़ाती है।
- कुछ लोग इसे सांस्कृतिक मानते हैं (“हर चीज़ के लिए library”), जो कमजोर standard libraries और ऐतिहासिक browser quirks से जुड़ा है।
- कई लोगों का तर्क है कि developers को अधिक सतर्क होना चाहिए और जिन dependencies को वे जोड़ते हैं, उनकी जिम्मेदारी स्वीकार करनी चाहिए।
Proposed Ecosystem Improvements
- छोटे utility packages की आवश्यकता कम करने के लिए मजबूत, अधिक पूर्ण standard libraries।
- packages और dependency graphs की social/quality scoring, transitive deps में explosion के लिए warnings के साथ।
- reuse को “काफी महंगा” बनाना (समय, review), ताकि developers हर नई dependency के प्रभाव को महसूस करें।
- dependencies को अधिक aggressively vendoring या locking करना; Go’s module proxy, Cargo’s yanking और vetting जैसे tools को सकारात्मक मॉडल के रूप में cited किया गया है।