JSR ไม่ใช่ตัวจัดการแพ็กเกจอีกตัว แต่เป็นเครื่องมือแบบใหม่

JSR - รีจิสทรีใหม่สำหรับการแชร์แพ็กเกจ JavaScript

• ในช่วงหลายปีที่ผ่านมา มีตัวจัดการแพ็กเกจใหม่อย่าง yarn และ pnpm เกิดขึ้นมาเพื่อปรับปรุงวิธีการดาวน์โหลดแพ็กเกจ
• แต่ npm package registry ซึ่งเป็นแกนหลักของระบบนิเวศ JavaScript แทบไม่ได้พัฒนาไปไหน
  • การอัปเดตที่น่าสนใจครั้งสุดท้ายคือแท็บ "files" ที่ถูกเพิ่มเข้ามาเมื่อหลายปีก่อน
• น่าแปลกที่ภาษา JavaScript ซึ่งเป็นที่รู้จักว่าเปลี่ยนแปลงและพัฒนาอย่างต่อเนื่อง กลับดูเหมือนถูกฉุดรั้งไว้ด้วยโมเดลการเผยแพร่ที่ล้าสมัย

ปัญหาของระบบโมดูล JavaScript

• ในตอนที่สร้าง Node ขึ้นมา ยังไม่มีระบบโมดูลมาตรฐานสำหรับ JavaScript ทำให้ npm registry และ Node เลือกใช้ระบบ CommonJS(require) เป็นค่าเริ่มต้น แม้ว่าจะมีข้อบกพร่องเชิงโครงสร้าง
  • และมันเป็นระบบที่ใช้ในเบราว์เซอร์ไม่ได้
• เกือบ 10 ปีก่อน ในปี 2015 ตัวภาษาเองได้รับไวยากรณ์ ES modules(import) มาใช้งาน
• ปัจจุบัน JavaScript ส่วนใหญ่เขียนด้วย ES modules แต่เส้นทางการเผยแพร่โมดูลเหล่านี้ยังคงซับซ้อน
  • โดยเฉพาะเมื่อมี TypeScript เข้ามาเกี่ยวข้อง
• ช่องว่างที่ชัดเจนในระบบนิเวศนี้เองที่ทำให้ JSR ถือกำเนิดขึ้น
  • JSR ไม่ใช่ตัวจัดการแพ็กเกจอีกตัว แต่เป็นรีจิสทรีเชิงเปลี่ยนผ่านที่ออกแบบมาเพื่อปฏิวัติวิธีการแชร์ JavaScript และ TypeScript ระหว่าง server-side runtime, เบราว์เซอร์ และเครื่องมือต่าง ๆ

คุณสมบัติและข้อดีของ JSR

• JSR ปรับปรุงกระบวนการเผยแพร่โค้ดอย่างรากฐาน ด้วยการลดความซับซ้อนที่รบกวนนักพัฒนามาอย่างยาวนาน
• ด้วยการเป็น ESM-only และให้ความสำคัญกับ TypeScript ก่อน JSR จึงช่วยขจัดภาระจากการต้องปรับแต่ง package.json และตัวเลือกคอมไพเลอร์ tsconfig ที่ซับซ้อนราวเขาวงกต
• ผ่านระบบให้คะแนนแพ็กเกจ JSR สนับสนุนแนวปฏิบัติที่ดีในการเผยแพร่โค้ด
  • คล้ายกับ pub.dev ของชุมชน Dart โดยจะให้คะแนนสูงกว่าแก่แพ็กเกจที่มีเอกสาร JSDoc ครบถ้วนสำหรับทุกสัญลักษณ์ที่ export ออกไป
• เช่นเดียวกับที่พบในระบบนิเวศภาษาโปรแกรมสมัยใหม่อื่น ๆ อย่าง Go และ Rust, JSR มีความสามารถสร้างเอกสารอัตโนมัติให้มาเป็นค่าเริ่มต้น

ความสัมพันธ์กับ npm

• JSR คือรีจิสทรี ไม่ใช่ไคลเอนต์อีกตัวสำหรับ npm registry
  • แต่ก็ไม่ได้หมายความว่าคุณต้องละทิ้งทุกอย่างของ npm หรือย้ายไปสู่ระบบนิเวศโมดูล JavaScript ที่แยกขาดจากกัน
• JSR ถูกออกแบบมาเพื่อเสริม npm registry ไม่ใช่เพื่อแทนที่ npm
  • แพ็กเกจบน JSR สามารถพึ่งพาแพ็กเกจ npm ได้ (เช่น อ้างอิงแพ็กเกจนี้)
• นอกจากนี้ แพ็กเกจ JSR ยังสามารถถูกใช้งานในซอฟต์แวร์เดิมที่ยึด npm เป็นศูนย์กลางได้
  • เพราะ JSR เองทำงานเป็น npm registry ที่แจกจ่าย npm-compatible tarball (เข้าถึงได้ที่ npm.jsr.io)
  • ทำให้สามารถนำแพ็กเกจ JSR ไปใช้ในซอฟต์แวร์ใด ๆ ที่ใช้ npm, yarn หรือ pnpm และยังผสานรวมกับ private registry ได้
• npm tarball ที่ JSR เผยแพร่นั้นผ่านการปรับแต่งมาแล้ว

ให้ความสำคัญกับความปลอดภัย

• ที่ Deno ความปลอดภัยถือเป็นลำดับความสำคัญสูงสุดของการพัฒนา JavaScript
• แม้จะไม่มีรีจิสทรีใดสามารถเฝ้าระวังโค้ดที่เผยแพร่ทั้งหมดได้อย่างครอบคลุม แต่ JSR มอบความโปร่งใสเกี่ยวกับผู้เผยแพร่และปกป้องกระบวนการเผยแพร่
• ด้วยการผสาน GitHub Actions และโทเค็น OIDC เข้าด้วยกัน JSR จึงสร้างหลักฐานแหล่งที่มาที่ตรวจสอบได้ขั้นสูงสำหรับซอฟต์แวร์อาร์ติแฟกต์ โดยอิงตาม supply chain levels และจัดเก็บไว้ใน Sigstore
  • สิ่งนี้ไม่เพียงรับประกันความแท้จริงของโค้ดเท่านั้น แต่ยังสร้างความเชื่อถือและความรับผิดชอบต่อสิ่งที่นักพัฒนานำไปใช้งานด้วย

ศูนย์กลางของการพัฒนา JavaScript

• JavaScript เป็นภาษากลางของโปรแกรมเมอร์จำนวนมาก จึงทั้งแพร่หลายและเข้าถึงได้ง่าย
• ภาษานี้ต้องการศูนย์กลางหรือ town square ที่นักพัฒนาสามารถแบ่งปันผลงานได้โดยไม่มีความซับซ้อนที่ไม่จำเป็น
• เราเชื่อว่า JavaScript จะยังคงเป็นศูนย์กลางของการพัฒนาซอฟต์แวร์ไปอีกยาวนาน และ JSR มีเป้าหมายเพื่อสนับสนุนความสำคัญนี้อย่างต่อเนื่อง
• JSR ไม่ได้เป็นเพียงเครื่องมืออีกชิ้นในระบบนิเวศ แต่สะท้อนถึงการเปลี่ยนแปลงพื้นฐานในวิธีที่เราคิดเกี่ยวกับการเผยแพร่ JavaScript และ TypeScript

[yangeok]

เหมือนว่า jsr จะดาวน์โหลดจาก npm ได้อยู่แล้วมั้ง,, 555

[zzzz2222]

php จงล่มไปซะ

[semjei]

ทำไมในบทความเกี่ยวกับ JS ถึงพูดถึง PHP ล่ะ??
ในฐานะคนที่กำลังทำโปรเจกต์ PHP อยู่ ก็รู้สึกสะเทือนใจครับ