npm v12 में backward compatibility तोड़ने वाले बदलावों की अग्रिम घोषणा

• npm install का डिफ़ॉल्ट व्यवहार अब security-focused होगा, इसलिए जो फीचर अब तक अपने-आप चलते थे वे अब यूज़र द्वारा स्पष्ट अनुमति देने पर ही (opt-in) काम करेंगे
• allowScripts का डिफ़ॉल्ट off — install किए जाने वाले external package में मौजूद preinstall·install·postinstall scripts डिफ़ॉल्ट रूप से block रहेंगे, और सिर्फ़ project में अनुमति दिए गए package ही चलेंगे
  • सिर्फ़ package install करते ही अपने-आप चलने वाले scripts को रोककर malicious code के घुसने की संभावना कम करने के लिए यह बदलाव किया गया है
  • node-gyp native build भी block की श्रेणी में आएगा, इसलिए ऐसे package जिनमें सिर्फ़ binding.gyp है और अलग install script नहीं है, उनका build भी रुक जाएगा (क्योंकि npm अंदरूनी तौर पर node-gyp rebuild चलाता है)
  • git·file·link के जरिए लाए गए package के prepare script भी इसी तरह block होंगे
  • उपयोग: npm approve-scripts --allow-scripts-pending से देखें कि किन package में scripts हैं → npm approve-scripts से सिर्फ़ भरोसेमंद चीज़ों को अनुमति दें, बाकी को npm deny-scripts से block करें → allow list package.json में सेव होगी, इसलिए उसे commit करें
• --allow-git का डिफ़ॉल्ट none — Git repository से सीधे लाए जाने वाले package (और वे आगे जो dependencies खींचते हैं, वे भी) डिफ़ॉल्ट रूप से block रहेंगे, और install के लिए --allow-git से अनुमति देनी होगी
  • इससे वह रास्ता बंद किया गया है जिसमें Git package के अंदर की .npmrc Git executable को ही बदल सकती थी (--ignore-scripts इस्तेमाल करने पर भी यह समस्या बची रहती थी) (npm 11.10.0+)
• --allow-remote का डिफ़ॉल्ट none — https tarball जैसे remote URL से लाए जाने वाले package (transitive dependencies सहित) डिफ़ॉल्ट रूप से block रहेंगे, और install के लिए --allow-remote से अनुमति देनी होगी (npm 11.15.0+)
  • हालांकि --allow-file और --allow-directory के डिफ़ॉल्ट इस v12 में नहीं बदलेंगे
• ऊपर के सभी बदलाव npm 11.16.0 या उससे ऊपर में पहले warning के रूप में उपलब्ध कराए जाएंगे, ताकि आधिकारिक release से पहले ही जाँच और तैयारी की जा सके
• v12 के release का अनुमानित समय जुलाई 2026 है

[GN⁺]

Hacker News टिप्पणियाँ

• पता नहीं मैं यह कैसे मिस कर गया कि npm को GitHub ने अधिग्रहित कर लिया था, लेकिन अचानक बहुत-सी बातें समझ आने लगी हैं
  Node ecosystem के इतने महत्वपूर्ण हिस्से के लिए इससे बदतर ठिकाना सोचना मुश्किल है

  • लगता है यह 2020 में हुआ था
    https://github.blog/news-insights/company-news/npm-is-joinin...
  • अधिग्रहण से पहले भी यह काफ़ी terrible था
  • यह सेवा को बदतर बनाना और नियंत्रण बढ़ाना, और आगे चलकर revenue pressure के लिए strategic positioning जैसा लगता है
    यही “Embrace, extend, extinguish” है
    https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

• postinstall scripts को बहुत पहले हटा दिया जाना चाहिए था, और ये NPM packages का कैंसर हैं
  कुछ fetch करते समय गहराई में nested, अनियंत्रित postinstall scripts का यूँ ही random चल पड़ना बहुत ज़्यादा होता है
  पता नहीं किसने और कब इसे अच्छा विचार माना था

  • मुझे post-install script वाली चिंता की जड़ ठीक से समझ नहीं आती
    आम तौर पर आप packaged dependency code को किसी न किसी बिंदु पर चलाने वाले ही होते हैं, और ज़्यादातर वही permissions होती हैं जो install process के दौरान होती हैं
    तो ये setup scripts, अच्छे हों या बुरे, बस npm से हटकर उस जगह चली जाएँगी जहाँ import या require होता है
    जब तक पूरा ecosystem Deno जैसे sandboxed environment में शिफ्ट नहीं होता, यह ज़्यादा से ज़्यादा एक छोटी रुकावट जैसा लगता है। शायद वही योजना हो
  • ऐसा बिल्कुल नहीं करना चाहिए, और इसके कई वैध use cases हैं
    अभी तुरंत दिमाग़ में https://www.npmjs.com/package/patch-package आता है
    उम्मीद है कि मौजूदा hysteria इस तरह के बेकार फ़ैसलों तक नहीं ले जाएगी

• लगता है यह बात 10 साल पहले सार्वजनिक होने के बाद से NPM के अंदर सैकड़ों बार चर्चा में आई होगी
  Shai Halud की वजह से अब इसे नज़रअंदाज़ करने लायक छोटा नहीं माना जा सकता

  • JavaScript का इतिहास मुझे इसलिए पसंद है क्योंकि यह लगभग developer mindset का condensed रूप लगता है
    “इसे बाद में ठीक करेंगे” लगभग हमेशा “धत्त, अब तो इसे ठीक करना ही पड़ेगा” बन जाता है
  • अच्छा, अब अगली बारी Python की है

• मैं जानना चाहता हूँ कि मौजूदा LTS Node versions, जहाँ तक याद है 22, 24, 26, क्या इस security fix का फ़ायदा देने के लिए bundled npm को v12 तक बढ़ाएँगे
  अभी इन सबमें npm v11 शामिल है

  • पहले भी Node की mid रिलीज़ों में npm major version upgrade आया है
    v18.19.0[1] और v20.10.0[2] में npm 9 से 10 पर अपग्रेड किया गया था
    [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
    [2]: https://nodejs.org/en/blog/release/v20.10.0
  • क्योंकि यह default change है, इसे security posture change माना जा सकता है, लेकिन actual security fix तो हर कोई पहले से लागू कर सकता है
    लेख में जैसा बताया गया है, बस सही defaults सेट करने हैं
    इस बदलाव की सबसे अच्छी बात यह है कि defaults बदलने पर वे परेशान करने वाले packages तुरंत टूटेंगे जो मानकर चलते हैं कि नया developer बस install चलाएगा और ये settings पहले से enabled होंगी
    उदाहरण के लिए, इससे scripts के executable होने की अपेक्षा रखने वाली आदत बंद हो सकती है

• सिर्फ़ लेख से यह साफ़ नहीं है, लेकिन लगता है script allowlist global setting नहीं बल्कि per-package अनुमति को support करती है
  इससे शायद संगठन-स्तर के ऐसे नियम बनाए रखना आसान होगा जिनमें सिर्फ़ खास packages के लिए scripts की अनुमति हो
  सोच रहा हूँ कि क्या package manager settings में इस तरह के unsafe defaults को रोकने के लिए कोई linter है

  • grep काफ़ी नहीं है क्या?

• सोच रहा हूँ कि क्या अभी भी Yarn इस्तेमाल करने की वजह है
  पता नहीं Yarn ने भी supply-chain attacks रोकने के लिए safeguards लागू किए हैं या नहीं
  अभी तक मुझे सिर्फ़ pnpm के बारे में पता था, npm का भी पीछे-पीछे आना अच्छा है

  • बिल्कुल है
    नवीनतम Yarn release, 4.x, लगभग ज़रूरत से ज़्यादा deterministic behavior सुनिश्चित करती है, और आप पूरी टीम में consistent behavior की अपेक्षा कर सकते हैं
    features के स्तर पर बहुत-सी छोटी details हैं, और जब आदत पड़ जाती है तो वे मिलकर बड़ा फ़र्क पैदा करती हैं
    अगला major release भी बेहतर performance और उन performance improvements पर आधारित ऐसे features के साथ इसी दिशा में आगे बढ़ेगा जिन्हें अब तक implement नहीं किया जा सका था
    संदर्भ के लिए, मैं Yarn का lead maintainer हूँ
  • मैंने एक ऐसे project पर काम किया है जो शुरुआत से v3 तक Yarn इस्तेमाल करता था, बहुत धीमा है लेकिन काम करता है
    supply-chain protection features भी हैं
    आख़िरकार धैर्य जवाब दे गया और हम pnpm पर चले गए, और CI तथा local development machines दोनों पर installs काफ़ी तेज़ हो गए
    LLM की मदद से migration में लगभग एक दिन लगा
  • एक अंतर इसकी वैकल्पिक install strategy है, जिसमें packages को node_modules में unpack नहीं किया जाता बल्कि compressed archives से सीधे चलाया जाता है
    https://yarnpkg.com/features/pnp
    यह कुछ-कुछ Java में .class file directory tree की जगह .jar इस्तेमाल करने जैसा है
    हालाँकि यह थोड़ा hacky है, और editor तथा tooling support काफ़ी बिखरा हुआ है
    छोटे files की संख्या बहुत कम होने से, अगर आपको मजबूरी में Windows पर काम करना पड़े तो यह ख़ासतौर पर तेज़ हो सकता है
    archives को git repository में भी रखा जा सकता है, जिससे internet और package registry पर निर्भरता हट सकती है
  • पता नहीं NPM क्या कर रहा है, लेकिन Yarn में dependency installs NPM से बहुत तेज़ हैं
  • जो लोग मेरे कमेंट को downvote कर रहे हैं, वे सवाल का जवाब भी दे सकते हैं
    मुझे सच में जवाब नहीं पता

• मुझे नहीं पता था कि npm, GitHub के स्वामित्व में है
  इससे बहुत-सी बातें समझ आती हैं

  • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 मार्च 2020, 571 टिप्पणियाँ, 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin...
    इनमें से कुछ को अब समय बीतने के बाद पढ़ना दिलचस्प है
    सबसे ऊपर वाला कमेंट यह था: “Microsoft हर चीज़ में अच्छा नहीं है, लेकिन GitHub acquisition ईमानदारी से उम्मीद से कहीं बेहतर निकला। GitHub पर Microsoft-केंद्रित policies थोपने के बजाय Microsoft ने product perspective से GitHub की चीज़ों को ज़्यादा अपनाया। GitHub अभी भी एक अलग कंपनी की तरह operate करता है”
  • NPM कंपनी 2020 में लगभग बंद होने की कगार पर थी
    उसे venture funding मिली थी, लेकिन वह sustainable business model नहीं ढूँढ पाई
    ecosystem को बचाने के लिए GitHub ने अधिग्रहण किया, और इस acquisition से GitHub को भी कोई बहुत बड़ा फ़ायदा नहीं हुआ
  • ज़्यादातर लोग यह जानते हैं, लेकिन जो बात वास्तव में बहुत कुछ समझाती है वह यह है कि GitHub, Microsoft के स्वामित्व में है
    और Microsoft ने GitHub को Azure पर शिफ्ट कर दिया
  • मुझे पता था कि यह GitHub के स्वामित्व में है, लेकिन npm blog की बजाय GitHub blog के release notes सीधे देखना मेरे लिए पहली बार था

• सोच रहा हूँ कि package.json की allowlist package version तक pin होती है, या सिर्फ़ package name तक

• allowScripts का default off होना अच्छा है
  [घड़ी देखता है] 18 महीने बाद अब जाकर pnpm की बराबरी कर रहा है क्या?

  • Java के Maven में ऐसा कुछ नहीं था, और मुझे कभी इसकी ज़रूरत महसूस नहीं हुई
    JavaScript में इसका उद्देश्य क्या है?