'everything' devs को अपने ही NPM packages हटाने से रोकता है
npm registry में एक prank “everything” package ने लगभग सभी अन्य packages पर dependencies घोषित कर दीं, जिससे left-pad incident के बाद बनाई गई उस policy का फायदा उठाया गया जो dependents वाले modules को unpublish करने से रोकती है। इससे maintainers अपने ही packages delete नहीं कर पा रहे हैं और registries में deletions, yanking, तथा code की long-term availability को कैसे संभाला जाए, इस पर बहस फिर तेज़ हो गई है। Commenters npm की design की Cargo, PyPI, और Maven जैसे alternatives से तुलना करते हैं, और package management की जटिलता, ecosystem reliability, तथा सार्वजनिक registries पर भरोसा करने के बजाय dependencies को vendor करने की आवश्यकता पर चर्चा को आगे बढ़ाते हैं.
NPM “everything” package और policy का टकराव
- “Everything” लगभग सभी अन्य NPM packages पर निर्भर करता है, जिससे NPM का वह नियम लागू हो जाता है कि जिन packages पर dependents हों, उन्हें unpublish नहीं किया जा सकता।
- Commenters note करते हैं कि यह rule left-pad incident के बाद ecosystem reliability की रक्षा के लिए लाया गया था।
- नतीजा: जिस package पर कोई और निर्भर हो, उसके authors effectively उसे delete करने की ability खो देते हैं; कुछ लोगों को लगता है कि यह NPM का “दोनों तरफ़ से फ़ायदा उठाने” जैसा है।
क्या packages deletable होने चाहिए?
- कुछ लोगों का तर्क है कि एक बार publish होने के बाद deletion impossible होनी चाहिए; registries के पास perpetual distribution rights होने चाहिए।
- अन्य लोग softer mechanisms चाहते हैं:
- “Yanking”/soft-delete (Cargo, NuGet, PyPI की तरह), ताकि पुराने lockfiles काम करते रहें लेकिन नए resolutions खराब versions से बचें।
- Hard remove की बजाय deprecation flags, UI में hiding, या clear warnings।
- Deletion के use cases: गंभीर bugs, deprecation, या sensitive/embarrassing content का accidental publication।
- Counterpoint: sensitive data upload होते ही वैसे भी expose हो चुकी होती है; सही fix secrets को rotate करना है, deletion नहीं।
इस specific issue के लिए mitigation ideas
- Dependency tree size पर hard limits (जैसे real-world P99 के आधार पर, exceptions के साथ) प्रस्तावित किए गए हैं।
- दूसरे लोग बताते हैं कि इससे पूरी तरह मदद नहीं मिलती: attacker बस कई छोटे “chunk” packages इस्तेमाल कर सकता है।
- कई लोगों के अनुसार असली fix NPM की yank/unpublish policy पर दोबारा विचार करना है, dependency limits नहीं।
- कुछ लोग इसके प्रभाव को मामूली असुविधा मानते हैं; दूसरों को यह साफ़ systemic failure लगता है।
Package management और ecosystem पर व्यापक बहसें
- PyPI, Rust के Cargo, Maven, NuGet, CPAN, Hackage, Nix, Bazel, Go modules से तुलना।
- बहुत से लोग बताते हैं कि malicious या problematic packages सभी ecosystems में मौजूद हैं; NPM अकेला नहीं है, लेकिन इसका scale और history मुद्दों को ज़्यादा visible बनाते हैं।
- एक universal, language-agnostic package manager पर बहस:
- समर्थक: dependency specification और file delivery generic problems हैं।
- विरोधी: language semantics, build systems, semver behavior, और security models से गहरी coupling एकीकरण को अवास्तविक बनाती है।
- JS/NPM ecosystem की कड़ी आलोचना कि यह chaotic और “unserious” है, low entry barriers, tiny packages, और deep dependency graphs से driven।
- दूसरे NPM का बचाव करते हैं कि यह मूलतः अच्छा है, लेकिन popularity और legacy design choices ने इसे overwhelmed कर दिया है।