npm v12 เตรียมประกาศการเปลี่ยนแปลงที่ทำให้ความเข้ากันได้ย้อนหลังใช้งานไม่ได้

 (github.blog)
1 คะแนน โดย GN⁺ 2026-06-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พฤติกรรมเริ่มต้นของ npm install จะเปลี่ยนเป็นแบบ เน้นความปลอดภัย โดยฟังก์ชันที่เคยทำงานอัตโนมัติจนถึงตอนนี้ จะเปลี่ยนเป็นทำงานได้ก็ต่อเมื่อ ผู้ใช้อนุญาตเอง (opt-in) เท่านั้น
  • ค่าเริ่มต้นของ allowScripts เป็น off — สคริปต์ preinstall·install·postinstall ที่อยู่ในแพ็กเกจภายนอกที่ติดตั้งจะถูกบล็อกเป็นค่าเริ่มต้น และจะรันได้เฉพาะแพ็กเกจที่โปรเจ็กต์อนุญาตไว้
    • เปลี่ยนเพื่อป้องกันสคริปต์ที่เคยรันอัตโนมัติแค่ติดตั้งแพ็กเกจก็ทำงาน ให้ลดช่องทางที่มัลแวร์จะแทรกเข้ามาได้
    • การบิลด์เนทีฟของ node-gyp ก็ถูกบล็อกด้วยเช่นกัน ดังนั้นแม้แพ็กเกจที่มีแค่ binding.gyp และไม่มี install script แยกต่างหาก ก็จะบิลด์ไม่ได้ (เพราะ npm เรียก node-gyp rebuild ภายใน)
    • สคริปต์ prepare ของแพ็กเกจที่นำเข้าผ่าน git·file·link ก็จะถูกบล็อกแบบเดียวกัน
    • วิธีใช้: ใช้ npm approve-scripts --allow-scripts-pending เพื่อตรวจสอบว่าแพ็กเกจใดมีสคริปต์ → ใช้ npm approve-scripts เพื่ออนุญาตเฉพาะที่เชื่อถือได้ และบล็อกที่เหลือด้วย npm deny-scripts → รายการที่อนุญาตจะถูกบันทึกใน package.json ดังนั้นควร commit ไว้
  • ค่าเริ่มต้นของ --allow-git เป็น none — แพ็กเกจที่ดึงตรงจาก Git repository (รวมถึงสิ่งที่แพ็กเกจนั้นดึงต่อมา) จะถูกบล็อกเป็นค่าเริ่มต้น และต้องอนุญาตด้วย --allow-git จึงจะติดตั้งได้
    • เป็นการปิดช่องทางที่ .npmrc ภายในแพ็กเกจ Git สามารถสลับเปลี่ยน Git executable เองได้ (--ignore-scripts ก็ยังป้องกันไม่ได้) (npm 11.10.0+)
  • ค่าเริ่มต้นของ --allow-remote เป็น none — แพ็กเกจที่ดึงมาจาก URL ระยะไกล เช่น https tarball (รวมถึงแบบส่งต่อ) จะถูกบล็อกเป็นค่าเริ่มต้น และต้องอนุญาตด้วย --allow-remote จึงจะติดตั้งได้ (npm 11.15.0+)
    • อย่างไรก็ตาม --allow-file·--allow-directory จะยังไม่มีการเปลี่ยนค่าเริ่มต้นใน v12 นี้
  • การเปลี่ยนแปลงทั้งหมดข้างต้นจะถูกปล่อยออกมาในรูปแบบ คำเตือนล่วงหน้าใน npm 11.16.0 ขึ้นไป เพื่อให้ตรวจสอบและเตรียมรับมือได้ก่อนเปิดตัวจริง
  • ช่วงเวลาที่คาดว่า v12 จะเปิดตัวคือ กรกฎาคม 2026

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-06-11
ความคิดเห็นจาก Hacker News

  • ไม่รู้เลยว่าพลาดเรื่องที่ npm ถูก GitHub เข้าซื้อกิจการไปได้ยังไง แต่จู่ๆ หลายอย่างก็เริ่มเข้าใจขึ้นมา
    นึกแทบไม่ออกว่าจะมีบ้านไหนที่แย่กว่านี้สำหรับส่วนที่สำคัญขนาดนี้ของ ecosystem ของ Node

    • ดูเหมือนว่าจะเกิดขึ้นในปี 2020
      https://github.blog/news-insights/company-news/npm-is-joinin...
    • ต่อให้ก่อนถูกซื้อกิจการ มันก็แย่มากอยู่แล้ว
    • มันดูเหมือนการ ทำให้บริการแย่ลงและเพิ่มการควบคุม เพื่อวางตำแหน่งเชิงกลยุทธ์สำหรับแรงกดดันด้านรายได้ในอนาคต
      นี่คือ “embrace, extend, extinguish”
      https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

  • สคริปต์ postinstall ควรถูกถอดออกไปนานแล้ว และเป็นเหมือนมะเร็งของแพ็กเกจ NPM
    เวลาดึงอะไรสักอย่างเข้ามา มักจะมี postinstall ที่ซ้อนลึกและไร้การควบคุมไปรันแบบสุ่มเต็มไปหมด
    ไม่รู้เลยว่าใครเคยมองว่านี่เป็นความคิดที่ดี

    • ผมไม่ค่อยเข้าใจแก่นของความกังวลเรื่องสคริปต์ post-install เท่าไร
      ปกติแล้วคุณก็ต้องรันโค้ด dependency ที่แพ็กมาอยู่ดีในสักจุดหนึ่ง และส่วนใหญ่ก็รันด้วยสิทธิ์เดียวกับขั้นตอนติดตั้ง
      งั้นสคริปต์ตั้งค่าแบบนี้ ต่อให้ดีหรือแย่ ก็แค่ย้ายจุดเริ่มจาก npm ไปอยู่ตรงที่เกิด import หรือ require
      ถ้าทั้ง ecosystem ไม่ได้ย้ายไปสู่ สภาพแวดล้อม sandbox แบบ Deno กันหมด มันก็ดูเป็นแค่สิ่งกีดขวางเล็กๆ เท่านั้น อาจจะเป็นแผนก็ได้
    • ไม่ควรทำแบบนั้นเด็ดขาด และมีกรณีใช้งานที่มีประโยชน์หลายอย่าง
      ตัวอย่างที่นึกออกทันทีคือ https://www.npmjs.com/package/patch-package
      หวังว่ากระแสตื่นตูมตอนนี้จะไม่จบลงด้วยการตัดสินใจไร้ประโยชน์แบบนี้

  • เรื่องนี้น่าจะถูก ถกกันภายใน NPM เป็นร้อยครั้ง ตั้งแต่ถูกเปิดเผยเมื่อ 10 ปีก่อน
    เพราะ Shai Halud ตอนนี้มันใหญ่เกินกว่าจะเมินได้แล้ว

    • ผมชอบที่ประวัติศาสตร์ของ JavaScript ดูเหมือนเป็นการกลั่น วิธีคิดแบบนักพัฒนา ออกมาอย่างเข้มข้น
      “เดี๋ยวค่อยแก้” แทบจะกลายเป็น “บ้าเอ๊ย ตอนนี้ต้องแก้แล้ว” เสมอ
    • ดีเลย ทีนี้ก็ถึงตา Python แล้ว

  • สงสัยว่า Node เวอร์ชัน LTS ปัจจุบัน เท่าที่จำได้คือ 22, 24, 26 จะอัปเกรด npm ที่ bundle มาเป็น v12 เพื่อให้ได้ประโยชน์จากการแก้ด้านความปลอดภัยนี้ไหม
    ตอนนี้ทุกตัวมากับ npm v11

    • ในอดีตเคยมี การอัปเกรด npm แบบเมเจอร์เวอร์ชัน ในรีลีสย่อยของ Node อยู่แล้ว
      ใน 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
    • นี่อาจมองได้ว่าเป็น การเปลี่ยนแปลงด้าน security posture เพราะเป็นการเปลี่ยนค่าดีฟอลต์ แต่ตัวการแก้ปัญหาความปลอดภัยเอง ทุกคนก็ใช้ได้อยู่แล้ว
      ก็แค่ตั้งค่าดีฟอลต์ให้เหมาะสมตามที่บทความบอก
      ข้อดีสุดของการเปลี่ยนนี้คือ เมื่อค่าดีฟอลต์เปลี่ยน นักพัฒนาใหม่ๆ จะเห็นทันทีว่าแพ็กเกจที่น่ารำคาญซึ่งตั้งสมมติฐานว่าแค่รัน install แล้วการตั้งค่านี้จะเปิดอยู่ กลับพังทันที
      เช่น อาจช่วยหยุดธรรมเนียมที่คาดหวังว่าสคริปต์จะต้องรันได้

  • จากบทความยังไม่ชัดเจน แต่ดูเหมือนว่า allowlist ของสคริปต์จะรองรับ การอนุญาตเป็นรายแพ็กเกจ ไม่ใช่การตั้งค่าระดับ global
    น่าจะทำให้รักษานโยบายระดับองค์กรที่อนุญาตสคริปต์เฉพาะบางแพ็กเกจได้ง่ายขึ้น
    สงสัยว่ามี linter ที่ใช้บล็อกค่าดีฟอลต์ไม่ปลอดภัยในคอนฟิกของ package manager แบบนี้ได้ไหม

    • grep ก็พอไม่ใช่เหรอ?

  • สงสัยว่ายังมี เหตุผลให้ใช้ Yarn อยู่ไหม
    ไม่รู้ว่า Yarn เองก็ทำกลไกป้องกัน supply chain attack ไว้หรือเปล่า
    ก่อนหน้านี้ผมรู้จักแค่ pnpm แต่ก็ดีที่ npm ตามมาทัน

    • มีอยู่แล้วแน่นอน
      Yarn รีลีสล่าสุด 4.x รับประกัน พฤติกรรมแบบกำหนดได้แน่นอน มากเสียจนแทบเกินไป และคุณคาดหวังพฤติกรรมที่สม่ำเสมอได้ทั้งทีม
      ในแง่ฟีเจอร์มีรายละเอียดเล็กๆ เยอะมาก ซึ่งพอคุ้นแล้วมันรวมกันจนเห็นความต่างชัด
      รีลีสเมเจอร์ถัดไปก็จะเดินแนวทางเดิมต่อ ทั้งประสิทธิภาพที่ดีกว่า และฟีเจอร์ที่ก่อนหน้านี้ทำไม่ได้เพราะต้องพึ่งการปรับปรุงด้านประสิทธิภาพนั้น
      เพื่อความโปร่งใส ผมคือ maintainer หลักของ Yarn
    • ผมเคยทำงานกับโปรเจกต์ที่ใช้ Yarn มาตั้งแต่ช่วงแรกจนถึง v3 ซึ่ง ช้ามากแต่ก็ใช้ได้
      มันก็มีฟีเจอร์ป้องกัน supply chain ด้วย
      สุดท้ายทนไม่ไหวเลยย้ายไป pnpm แล้วการติดตั้งเร็วขึ้นมากทั้งใน CI และบนเครื่องพัฒนาโลคัล
      ใช้ความช่วยเหลือจาก LLM แล้วใช้เวลาประมาณวันหนึ่งในการย้าย
    • จุดต่างอย่างหนึ่งคือกลยุทธ์การติดตั้งที่เลือกได้ โดยไม่แตกแพ็กเกจลง node_modules แต่ รันตรงจากไฟล์บีบอัด archive เลย
      https://yarnpkg.com/features/pnp
      มันค่อนข้างคล้ายกับการใช้ .jar ใน Java แทน directory tree ของไฟล์ .class
      เพียงแต่มันออกจะแฮ็กๆ หน่อย และการรองรับจาก editor กับเครื่องมือต่างๆ ก็ไม่สม่ำเสมอ
      เพราะจำนวนไฟล์ย่อยน้อยกว่ามาก มันเลยอาจเร็วกว่าโดยเฉพาะถ้าคุณจำเป็นต้องทำงานบน Windows
      คุณยังเอา archive เข้า git repository ได้ด้วย จึงตัดการพึ่งพาอินเทอร์เน็ตและ package registry ออกไปได้
    • ไม่รู้ว่า NPM ทำอะไรอยู่บ้าง แต่ Yarn ติดตั้ง dependency ได้เร็วกว่า NPM มาก
    • คนที่กดโหวตลบคอมเมนต์ผม จะตอบคำถามก็ได้นะ
      ผมไม่รู้คำตอบจริงๆ

  • ไม่เคยรู้มาก่อนว่า npm เป็นของ GitHub
    แบบนี้หลายอย่างก็อธิบายได้เลย

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 มีนาคม 2020, 571 ความเห็น, 1829 คะแนน) - https://github.blog/news-insights/company-news/npm-is-joinin...
      บางส่วนพอกลับมาอ่านตอนนี้ก็น่าสนใจดี
      คอมเมนต์บนสุดตอนนั้นคือ “Microsoft ไม่ได้ทำทุกอย่างได้ดีหมด แต่พูดตามตรง การเข้าซื้อ GitHub เป็นไปได้ดีกว่าที่คาดไว้มาก แทนที่จะบังคับนโยบายแบบ Microsoft-centric กับ GitHub กลับกลายเป็นว่า Microsoft รับเอาหลายอย่างของ GitHub ไปใช้ในมุมมองผลิตภัณฑ์มากกว่า GitHub ยังดำเนินงานเหมือนเป็นบริษัทแยกอยู่”
    • บริษัท NPM ตอนปี 2020 เกือบจะล้มละลายอยู่แล้ว
      ได้เงินลงทุนแบบ venture มาก็จริง แต่หาธุรกิจที่ยั่งยืนไม่เจอ
      GitHub เข้าซื้อเพื่อช่วยชีวิต ecosystem และดีลนี้ก็แทบไม่ได้สร้างประโยชน์ก้อนใหญ่ให้ GitHub เท่าไร
    • คนส่วนใหญ่รู้เรื่องนี้อยู่แล้ว แต่สิ่งที่อธิบายอะไรได้จริงๆ มากคือ GitHub เป็นของ Microsoft
      และ Microsoft ก็ย้าย GitHub ไปไว้บน Azure
    • ผมรู้ว่าเป็นของ GitHub อยู่แล้ว แต่ครั้งนี้เป็นครั้งแรกที่ได้เห็น release note อยู่บน บล็อกของ GitHub โดยตรง ไม่ใช่บล็อกของ npm

  • สงสัยว่า allowlist ใน package.json นี่ ล็อกถึงเวอร์ชันของแพ็กเกจ ด้วยไหม หรือแค่ล็อกชื่อแพ็กเกจอย่างเดียว

  • ดีเลยที่ allowScripts ปิดเป็นค่าดีฟอลต์
    [ดูนาฬิกา] แปลว่า npm ใช้เวลา 18 เดือน กว่าจะตาม pnpm ทันงั้นเหรอ?

    • Maven ของ Java ไม่มีอะไรแบบนี้ และผมก็ไม่เคยรู้สึกว่าจำเป็น
      ฝั่ง JavaScript เขาทำสิ่งนี้ไปเพื่ออะไร?