npm v12 में आने वाले breaking compatibility changes

 (github.blog)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • npm v12 में npm install के security-related defaults auto execution और resolution से बदलकर explicit allow मॉडल में हो जाएंगे, और npm 11.16.0 या उससे ऊपर में warnings के जरिए पहले से इनकी जांच की जा सकती है
  • allowScripts का default off हो जाएगा, जिससे उन dependencies के preinstall, install, postinstall scripts और implicit node-gyp rebuild, साथ ही git·file·link dependencies के prepare scripts का execution block हो जाएगा जिन्हें explicitly allow नहीं किया गया है
  • npm approve-scripts --allow-scripts-pending से उन packages को देखा जा सकता है जो block होंगे, और npm approve-scripts तथा npm deny-scripts से allow·block तय करने के बाद बनी allowlist को package.json में commit करना होगा
  • --allow-git का default none में बदल जाएगा, जिससे --allow-git से explicitly allow नहीं की गई direct और transitive Git dependencies का resolution रुक जाएगा
  • Git dependencies की .npmrc द्वारा --ignore-scripts इस्तेमाल होने पर भी Git executable को override करके code execution तक पहुंचने वाले path को block किया जाएगा
  • --allow-remote का default none में बदल जाएगा, जिससे --allow-remote से explicitly allow नहीं किए गए https tarball जैसी remote URL dependencies का resolution रुक जाएगा
  • npm v12 में --allow-file और --allow-directory के defaults में कोई बदलाव नहीं है
  • तैयारी की प्रक्रिया: npm 11.16.0 या उससे ऊपर upgrade करें, फिर सामान्य install चलाकर warnings की समीक्षा करें, सिर्फ trusted packages को approve करें, और upgrade के बाद सिर्फ approved scripts ही चलते रहेंगे
  • संबंधित दस्तावेज़: npm approve-scripts, npm deny-scripts, allow-scripts config

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News टिप्पणियाँ

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

  • 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 में इसका उद्देश्य क्या है?