Deno 2.4 ออกแล้ว

 (deno.com)
2 คะแนน โดย GN⁺ 2025-07-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • deno bundle ถูกนำกลับมาอีกครั้งโดยใช้ esbuild เป็นฐาน ทำให้สามารถสร้างบันเดิลไฟล์เดียวสำหรับทั้งเซิร์ฟเวอร์และเบราว์เซอร์ พร้อม tree shaking และ การปรับแต่งให้เหมาะสม อัตโนมัติ
  • รองรับ การ import ข้อความ/ไบต์ และทำให้การรองรับ OpenTelemetry ในตัว เสถียร แล้ว ช่วยเสริมประสบการณ์ด้าน observability และการใช้งานไฟล์ภายนอก
  • มีการปรับปรุงครั้งใหญ่ทั้ง แฟลก --preload ใหม่, deno update ที่ช่วยให้จัดการ dependency ได้สะดวกขึ้น, การวัด coverage ของสคริปต์, การจัดการสิทธิ์, ไปจนถึงความเข้ากันได้กับ Node.js API
  • ยังเพิ่มประสิทธิภาพการรองรับ LSP, Jupyter, bench/coverage, tsconfig และการปรับปรุงความสะดวกในการใช้งานอีกหลากหลายด้าน

สรุปการเปลี่ยนแปลงหลักและฟีเจอร์ใหม่ใน Deno 2.4

การกลับมาของ deno bundle

  • ใน Deno 2.4 มีการนำซับคอมมานด์ deno bundle สำหรับสร้าง JavaScript bundle แบบไฟล์เดียว กลับมาอีกครั้ง พร้อมเอนจิน esbuild
  • รองรับทั้งเซิร์ฟเวอร์และเบราว์เซอร์ และสามารถ bundle dependency จาก npm, JSR ได้อย่างไม่มีปัญหา
  • รองรับ tree shaking และ code optimization (minify) อัตโนมัติ ทำให้จัดการได้สะดวกขึ้น
  • ในอนาคตมีแผนเพิ่มความสามารถในการขยายและปรับแต่งกระบวนการ bundle แบบโปรแกรมได้ผ่าน runtime API และ ปลั๊กอิน

รองรับการ import ข้อความและไบต์

  • มีแฟลก --unstable-raw-imports เพื่อให้สามารถฝัง ไฟล์ข้อมูลภายนอก เช่น ข้อความ ไบนารี และรูปภาพ ลงใน JavaScript module graph ได้
  • เดิมทีต้องอ่านไฟล์ภายนอกผ่าน file I/O แต่ตอนนี้สามารถระบุชนิดไฟล์ในคำสั่ง import เพื่อใช้งาน ข้อมูลไบต์/ข้อความโดยตรง ได้แล้ว
  • ฟีเจอร์นี้ทำงานได้ทั้งตอน bundle และ compile ช่วยให้ทำ asset embedding ลงในผลลัพธ์ได้ง่ายขึ้น
  • เมื่อใช้ร่วมกับการรองรับ import เดิมอย่าง JSON และ Wasm ก็ช่วยให้จัดการหลายฟอร์แมตไฟล์ได้อย่าง เป็นมิตรกับสเปก มากขึ้น
  • แม้ข้อกำหนดมาตรฐานยังอยู่ระหว่างการหารือ แต่ Deno ก็พยายามสะท้อนทั้งความก้าวหน้าของฟีเจอร์และทิศทางของมาตรฐานอย่างสมดุล

การรองรับ OpenTelemetry ในตัวเสถียรแล้ว

  • การรองรับ OpenTelemetry ในตัว ที่เปิดตัวในเวอร์ชัน 2.2 ได้เสถียรสมบูรณ์แล้วใน 2.4
  • เพียงตั้งค่าตัวแปรสภาพแวดล้อม OTEL_DENO=1 ก็สามารถเปิดใช้ การเก็บ log, metric, trace แบบอัตโนมัติได้โดยไม่ต้องใช้แฟลกเพิ่มเติม
  • รองรับความเข้ากันได้กับ Node.js แบบ ไม่ต้องตั้งค่า รวมถึงสภาพแวดล้อม deployment ของ Deno Deploy
  • ยังสามารถทำ การเชื่อมโยง/สังเกตอัตโนมัติ ระหว่าง log จาก console.log และ HTTP request ได้ด้วย
  • เนื่องจากมีผลต่อการใช้ทรัพยากร จึงยังควรควบคุมผ่านตัวแปรสภาพแวดล้อม

แฟลก --preload สำหรับตั้งค่าสภาพแวดล้อมก่อนรัน

  • เพิ่มแฟลก --preload สำหรับรันโค้ดล่วงหน้าก่อนสคริปต์หลัก เพื่อใช้กับงานอย่าง การเปลี่ยนแปลงสภาพแวดล้อมส่วนกลาง การโหลดข้อมูล หรือการลงทะเบียนโมดูลที่ต้องพึ่งพา
  • มีประโยชน์กับการทำ platform setup หลายรูปแบบ เช่น การปรับแต่งแพลตฟอร์มหรือรีเซ็ต global object
  • ใช้ได้กับคอมมานด์หลักอย่าง deno run, deno test, deno bench

ทำให้การจัดการ dependency ง่ายขึ้น: deno update

  • เพิ่มซับคอมมานด์ deno update เพื่อ อัปเดต dependency ของ npm และ JSR เป็นเวอร์ชันล่าสุดโดยอัตโนมัติ
  • รองรับการอัปเดตหลาย dependency พร้อมกัน และการอัปเดตแบบละเอียดตาม ความเข้ากันได้ของ Semver
  • มี alias ของ deno outdated --update เพื่อให้ใช้งานได้สะดวกขึ้น

script coverage: deno run --coverage

  • ไม่ได้เก็บ coverage ได้เฉพาะแต่ละเทสต์เท่านั้น แต่ยังเก็บได้ทั้ง การรันทั้งหมดที่มี subprocess รวมอยู่ด้วย
  • รองรับการจัดการข้อมูลอย่างยืดหยุ่นหลายรูปแบบ เช่น ผ่านตัวแปรสภาพแวดล้อม DENO_COVERAGE_DIR
  • เพิ่มการรองรับ dark mode ในรายงาน coverage แบบ HTML

ตัวแปรสภาพแวดล้อมด้านความเข้ากันได้ของ Deno DENO_COMPAT=1

  • เพิ่มตัวแปร DENO_COMPAT=1 เพื่อปรับปรุง ความสะดวกและความเข้ากันได้ สำหรับโปรเจ็กต์ที่อิงกับ ecosystem ของ npm และ package.json
  • จะเปิดใช้แฟลกไม่เสถียรหลายตัวโดยอัตโนมัติ และมีแผนขยายการรองรับเพิ่มเติม เช่น การละ prefix ของ npm ในอนาคต

การจัดการสิทธิ์และความปลอดภัยที่ดีขึ้น

  • แฟลก --allow-net รองรับ subdomain wildcard และช่วง CIDR
  • เพิ่มแฟลก --allow-import สำหรับจำกัดโฮสต์ที่อนุญาตให้ import ได้ และ --deny-import สำหรับบล็อกอย่างชัดเจน
  • Deno.permissions API รองรับ query ประเภท "import" อย่างเป็นทางการ
  • การใช้ Deno.execPath() ไม่จำเป็นต้องมีสิทธิ์อ่านอีกต่อไป ทำให้ใช้งานพาธของไฟล์ executable ได้ง่ายขึ้น

conditional package.json exports

  • รองรับ conditional exports ในแพ็กเกจ npm ช่วยเสริมการรองรับ ecosystem ต่าง ๆ โดยเฉพาะการตั้งค่าเซิร์ฟเวอร์ของ React
  • สามารถใช้แฟลกเงื่อนไขของผู้ใช้เพื่อปรับพฤติกรรม import ได้อย่างยืดหยุ่น

รองรับ bare specifier ใน deno run

  • สามารถใช้ alias (bare spec) ที่ตั้งไว้ใน "imports" ของ deno.json เป็น entry point ของคำสั่งได้
  • ช่วยเพิ่มความสะดวกอย่างมากในด้าน productivity และ การทำงานอัตโนมัติของการจัดการโมดูล

ปรับปรุงการจัดรูปแบบโค้ดสำหรับฟอร์แมตอย่าง XML, SVG

  • deno fmt รองรับการจัดรูปแบบอัตโนมัติของไฟล์เทมเพลตหลากหลายชนิด เช่น .xml, .svg, .mustache

เสริมการรองรับ tsconfig.json

  • ปรับปรุงความแม่นยำในการรู้จักออปชันต่าง ๆ เช่น references, extends, files, include, exclude
  • เพิ่มความเข้ากันได้กับเฟรมเวิร์กฟรอนต์เอนด์สมัยใหม่ เช่น Vue, Svelte, Solid, Qwik

เพิ่มความเข้ากันได้ของตัวแปร global และ API ของ Node

  • มีการเปลี่ยนแปลงให้ global object ของ Node.js อย่าง Buffer, global, setImmediate, clearImmediate มีอยู่ในโค้ดของผู้ใช้เสมอ
  • global ที่เดิมใช้ได้เฉพาะกับแพ็กเกจ npm ก็สามารถ ใช้งานได้ทันทีโดยไม่ต้องใช้คอมมานด์แฟลก
  • บรรลุความเข้ากันได้ มากกว่า 95% สำหรับ node:buffer, node:events, node:querystring, node:quic, node:wasm และจะขยายต่อไปอย่างต่อเนื่อง
  • เวอร์ชันเริ่มต้นของ type @types/node ก็อัปเดตเป็น 22.15.14 แล้ว

การเปลี่ยนแปลงการจัดการแพ็กเกจ npm แบบ local

  • ชื่อออปชันสำหรับเชื่อมต่อแพ็กเกจ npm แบบ local เปลี่ยนจาก patch เป็น links เพื่อให้ตรงกับความหมายของ npm link
  • หากยังใช้ออปชันเดิมจะมี คำเตือน deprecation เพื่อให้จัดการแพ็กเกจได้ชัดเจนขึ้น

การปรับปรุง LSP และ productivity สำหรับนักพัฒนา

  • มีทั้งการปรับปรุงประสิทธิภาพและความสามารถของ LSP รวมถึงการรองรับ Unix/Vsock socket ของ fetch, onListen callback ของเซิร์ฟเวอร์, การจัดการ Jupyter kernel, การอ่านข้อความใน lint plugin และความเข้ากันได้ของ Markdown ในตาราง bench/coverage
  • ยังมีการปรับปรุงใหม่อย่างการรองรับสัญญาณ Ctrl+Close บน Windows (windows SIGHUP) และฟอร์แมต Markdown สำหรับข้อความผลลัพธ์ของ bench/coverage

ขอบคุณชุมชนและผู้มีส่วนร่วม

  • การพัฒนา Deno 2.4 ได้รับแรงสนับสนุนสำคัญจาก ผู้มีส่วนร่วมในชุมชนที่หลากหลาย ทั้งการมีส่วนร่วมและฟีดแบ็ก
  • รายละเอียดเพิ่มเติมและรายการเปลี่ยนแปลงแบบเต็มดูได้ที่ หน้า GitHub Releases

สรุป

  • Deno 2.4 มาพร้อมความก้าวหน้าครั้งใหญ่ในหลายด้าน ทั้ง bundle, การ import ไฟล์ภายนอก, observability, สิทธิ์/ความปลอดภัย, ความเข้ากันได้, productivity
  • ช่วยให้สัมผัสประสบการณ์ สภาพแวดล้อมการพัฒนาแบบผสานรวมที่ใช้ง่ายและทรงพลัง ได้ทั้งกับ workflow การพัฒนาและโปรเจ็กต์บน ecosystem ของฟรอนต์เอนด์สมัยใหม่และ Node
  • ข้อมูลเพิ่มเติม ข่าวล่าสุด และประวัติการเปลี่ยนแปลงทั้งหมด สามารถดูได้จากเอกสารทางการ บล็อก และหน้า GitHub Releases

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

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

 
GN⁺ 2025-07-08
ความคิดเห็นจาก Hacker News

  • ชอบแนวคิดของ Deno มาก เลยเคยลองนำ Deno.json, JSR, modern import, Deno Deploy ฯลฯ ไปใช้กับโปรเจ็กต์ monorepo ที่มี Next.js, Hono และ private package ต่าง ๆ ให้ได้มากที่สุด Hono ทำงานได้เรียบร้อยดี แต่ Next.js ไม่เป็นแบบนั้น และยังเจอปัญหาเรื่อง type ที่พังแบบแปลก ๆ ด้วย จำได้ว่าการเลือกปลายทาง deploy (เช่น Vercel) ก็เป็นปัญหาเหมือนกัน เลยแชร์ปัญหาเล็ก ๆ ที่เจอไว้เป็นตัวอย่างผ่านลิงก์ issue ตรงกันข้าม Bun แม้ประสบการณ์ใช้งานจะไม่เนี้ยบแบบ Deno แต่ก็ต้องคิดน้อยกว่าและให้ความรู้สึกว่าแค่ "ใช้ได้" อย่างไรก็ดี Bun ก็ยังไม่สมบูรณ์ เช่น Vercel ยังไม่รองรับ Bun runtime

    • มีคำแนะนำว่าที่ฝืนใช้แบบนั้นเป็นเพราะสแตกที่เลือกยังยึด npm เป็นศูนย์กลางอยู่มาก โดยเฉพาะในสภาพแวดล้อมที่มี private npm package จำนวนมาก จุดหวานของแนวทางแบบ Deno น่าจะอยู่ที่การเลือกสแตกที่เป็นมิตรกับ Deno หรือ ESM โดยธรรมชาติ คิดว่าประสบการณ์กับการใช้ Lume หรือการ target ไปที่ Deno Deploy นั้นดีมาก (คะแนน JSR ก็ช่วยให้ค้นหาไลบรารีที่น่าสนใจและรองรับ ESM ได้ดีด้วย) แน่นอนว่าการให้เริ่มด้วยสแตกใหม่ทั้งหมดนั้นในโลกจริงทำได้ยาก และการลงทุนกับ Next.js เป็นต้นก็มีมากแล้ว จึงรู้สึกลำบากที่จะเชียร์ Deno แต่ถ้าจะให้ข้อดีของ Deno โดดเด่นจริง ๆ ก็น่าจะเป็นสภาพแวดล้อมที่เริ่มจากศูนย์ด้วยเครื่องมือที่เป็น Deno-native และ ESM-native ทั้งชุด อนึ่ง ความเข้ากันได้กับ npm ของ Deno ก็ดีขึ้นเรื่อย ๆ และใน release note ของ 2.4 ก็มีการปรับปรุงด้านนี้ด้วย ในสภาพแวดล้อม full-stack การใช้ package.json เป็นหลักแทน deno.json อาจเข้ากันได้ดีกว่า ดังนั้นในระยะยาวถึงจะดัน deno.json ก็ยังแนะนำการตั้งค่าบนฐาน package json ด้วย

    • พอลองใช้ Deno ในโหมดเข้ากันได้กับ npm ก็รู้สึกว่ามันทำงานได้ดีกว่าที่คาดไว้ ค่อนข้างคล้ายกับวิธีใช้ Bun มาก ถ้าเรียก deno install ในไดเรกทอรีที่มี package.json มันจะสร้าง node_modules แบบบางให้ และยังสามารถรันสคริปต์ที่นิยามใน package.json ได้ด้วยคำสั่ง deno task something แต่แนวทางเฉพาะของ Deno มักใช้เวลามากและทำให้อึดอัด พอจะกลับไปใช้สภาพแวดล้อม node/npm ก็ยิ่งปวดหัว สรุปคือการใช้ Deno ร่วมกับ package.json นั้นราบรื่นกว่า

    • ตอนแรกทุ่มให้ Deno เต็มตัว แต่มีปัญหาเล็ก ๆ น้อย ๆ มากเกินไปจนเหนื่อย เมื่อเทียบกันแล้ว Bun กลับทำงานได้ดีโดยแทบไม่ต้องใส่ใจอะไรเป็นพิเศษ

  • คนมักประเมินความเข้ากันได้กับ node ของ Deno ต่ำเกินไป คาดว่าการมี compat environment variable จะช่วยให้แพร่หลายมากขึ้น ถ้าคำสั่งอย่าง denon เปิดให้อัตโนมัติได้ก็น่าจะสะดวกขึ้น

    • จากประสบการณ์ของฉัน ความเข้ากันได้กับ node ของ Deno ต่ำกว่าที่หวังไว้ ย้ายโปรเจ็กต์ง่าย ๆ ขนาดราว 100~200 บรรทัดมา Deno ใช้เวลาประมาณ 1 ชั่วโมง ทั้งที่จริงควรจบใน 5~10 นาที เจอทั้งเมธอดบางส่วนของ node ที่ไม่รองรับ เอกสารที่ไม่ดีพอ และแม้แต่ฟังก์ชันพื้นฐานก็ยังต้องไปดาวน์โหลดจาก URL แปลก ๆ โดยตรง ตอนพยายามพอร์ต test suite สุดท้ายก็ยอมแพ้ โดยเฉพาะกระบวนการเปลี่ยนจาก CommonJS(CJS) ไปเป็น ESM นั้นทรมานกว่าที่คิดมาก และไม่สามารถเปลี่ยนได้ง่ายอย่างที่เอกสารทางการของ Deno อธิบายไว้เลย สุดท้ายมีประสบการณ์ว่าพอร์ตทั้งไลบรารีไม่ได้

    • เมื่อก่อนค่อนข้างมอง Deno ในแง่ดี แต่ตอนนี้ไม่รู้สึกว่ามีเหตุผลอะไรให้ใช้ Deno แทน Bun

  • มีคนชื่นชมว่ารายการการเปลี่ยนแปลงล่าสุดของ Deno ดีมาก ตอนนี้ใช้งาน Deno อย่างพอใจกับงานเขียนสคริปต์สุ่ม ๆ / glue code (ส่วนงานแมชชีนเลิร์นนิงใช้ python/uv) และก็คาดหวังกับการรองรับ gRPC และคำสั่ง bundle ในอนาคต

  • ยังรู้สึกแปลกที่ Deno ยังใช้งานบน FreeBSD ได้ไม่ดีนัก Rust-based V8 binding ยังไม่ได้ถูกพอร์ต

    • สงสัยว่าจริง ๆ แล้วในหมู่นักพัฒนา JavaScript ยุคนี้มีคนใช้ FreeBSD มากแค่ไหน

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

    • ดูเหมือนว่าจะมีการลงทะเบียนไว้ในพอร์ตสำหรับ FreeBSD แล้ว

    • พอเข้าใจได้อย่างมากว่าทำไมถึงไม่ทุ่มแรงสนับสนุน FreeBSD

  • มีความเห็นว่าเหตุผลที่ Deno ยังไม่ถูกใช้ในโปรดักชันอย่างแพร่หลายคือการไม่มีฐานข้อมูลช่องโหว่มาตรฐาน แม้จะพอแก้ด้วยความเข้ากันได้กับ npm แบบ 100% ได้ แต่ถ้าทำแบบนั้น deno package ยอดนิยมส่วนใหญ่ก็จะหลุดออกจากขอบเขตไปอยู่ดี โดยพื้นฐานแล้วการไม่มี package manager ส่วนกลาง (ซึ่งเป็นการออกแบบโดยตั้งใจ) คือความท้าทาย จึงถามว่ามีความคืบหน้าในเรื่องนี้หรือยัง

    • มีคนแย้งว่าถ้าการไม่มีฐานข้อมูลช่องโหว่เป็นปัญหาใหญ่จริงในโปรดักชัน งั้น C/C++ ก็คงใช้ไม่ได้เหมือนกัน เพราะในทางปฏิบัติ C/C++ ก็ตรวจประเด็นความปลอดภัยผ่านฐานข้อมูลอย่าง CVE/GHSA ที่ไม่ยึดติดกับภาษาอยู่แล้ว อนึ่ง ในโลกของ C มักมีกรณีที่แค่เวนเดอร์ไฟล์ภายนอกมาใช้เฉย ๆ โดยไม่ติดตามเวอร์ชันด้วยซ้ำ อีกทั้งยังมีไฟล์ deno.lock อยู่ ดังนั้นคนที่ใส่ใจสามารถใช้มันตรวจฐานข้อมูลช่องโหว่กับเวอร์ชันที่ใช้งานได้

    • โครงสร้างที่ดึงแพ็กเกจมาจาก URL โดยตรง (เช่น GitHub) นั้น Go ก็คล้ายกัน ดังนั้นประเด็นเดียวกันนี้ก็ใช้กับ Go ได้เหมือนกัน

  • ชอบที่มีการนำ subcommand bundle กลับมาอีกครั้ง รู้สึกดีที่ไม่ต้องใช้วิธีอ้อมที่ยุ่งยากแล้ว

  • แปลกใจที่เลือกใช้ esbuild สำหรับงาน bundle แทน Rolldown ที่เขียนด้วย Rust ทั้งที่ Rolldown ก็กำลังจะออก v1 เร็ว ๆ นี้แล้ว

    • esbuild ตอนนี้เสถียรและ mature มาก ขณะที่ Rolldown ยังเปลี่ยนแปลงเร็วอยู่ ดังนั้นการเลือก esbuild จึงเป็นตัวเลือกที่ปลอดภัยกว่า

  • ชอบทิศทางของ Deno มาก และรู้สึกว่าเดิมที Node ก็ควรออกมาเป็นแบบนี้ แต่สิ่งที่กังวลคือ Deno อาจถูกกระแส "ไฮป์" ของคู่แข่งพาให้เปลี่ยนตามโดยไม่มีจุดยืนของตัวเอง

    • จะว่าไป Deno เองก็ดูเหมือนเคยถูกมองว่าเป็นคู่แข่งสาย "ไฮป์" ของ Node.js อยู่เหมือนกัน

  • ได้ยินคำชมเกี่ยวกับ Deno มาเรื่อย ๆ เลยเริ่มคิดว่าอาจลองใช้ js ดูสักครั้ง

    • ถ้าเป็นตอนนี้ การเริ่มด้วย TS ตั้งแต่แรกก็เป็นตัวเลือกที่ดีเหมือนกัน

  • เชียร์ Deno ในมุมความปลอดภัย แต่เคยรู้สึกติดใจที่เว็บทางการแนะนำให้ผู้ใช้ติดตั้งแบบ curl mywebsite.com/foo.sh | sh แน่นอนว่าแต่ละคนยอมรับความเสี่ยงไม่เท่ากัน แต่ถ้าอย่างน้อยดาวน์โหลดไฟล์มาก่อนแล้วค่อยรัน ก็ยังมีโอกาสให้ตัวเองหรือแอนติไวรัสตรวจสอบได้ Node/Deno + npm ecosystem โดยพื้นฐานแล้วเป็นโครงสร้างที่ต้องอาศัยความเชื่อใจสูงอยู่แล้ว ในไกด์ทางการก็มีตัวเลือก npm install -g deno นอกจาก curl | sh ด้วย ซึ่ง npm อย่างน้อยก็ยังมีการตรวจสอบความสมบูรณ์ของไฟล์และการสแกนมัลแวร์เบื้องต้น เลยดูปลอดภัยกว่าในเชิงเปรียบเทียบ แม้เว็บไซต์ deno.land จะปลอดภัยในระดับ codebase แต่ในเชิงปฏิบัติการก็รับประกัน 100% ไม่ได้ จึงมองว่า curl | sh ไม่ใช่แนวปฏิบัติด้านความปลอดภัยที่ดี

    • มีคนไม่เห็นด้วยกับตรรกะนี้ โดยมองว่าสคริปต์ติดตั้งส่วนใหญ่สุดท้ายก็มีหน้าที่ดาวน์โหลดไบนารีขนาดหลายร้อยถึงหลายล้านบรรทัดที่ผู้เขียนคนเดียวกันสร้างขึ้นมาแล้วเอามารันอยู่ดี ถ้าถึงขั้นไม่เชื่อใจผู้เขียนเลยจนสมมติว่าเซิร์ฟเวอร์อาจปล่อยมัลแวร์เฉพาะบาง IP ได้ ก็ย่อมมีโอกาสฝังมัลแวร์ลงในระดับไบนารีได้เหมือนกัน ดังนั้นถ้าไม่ไว้ใจขนาดนั้นก็ควรไม่ใช้โปรเจ็กต์นั้นตั้งแต่แรก ประเด็น curl | sh แพร่หลายเพราะเป็นข้อโต้แย้งที่ง่ายและพูดซ้ำได้มากกว่า แต่การรีวิวโค้ดหลายล้านบรรทัดต่างหากที่เป็นปัญหาความปลอดภัยจริง ถ้ากังวลถึงระดับการโจมตี MITM โดยหน่วยงานรัฐ ก็อาจมีทางเดียวคือตัดความเชื่อถือจากอินเทอร์เน็ตภายนอกไปเลย

    • มีข้อชี้ว่าการ onboarding ผู้ใช้ใหม่ก็มีความยากอยู่ ต่อให้แนะนำให้ใช้ npm ก็ต้องติดตั้ง npm มาก่อน ซึ่งเว็บทางการ npm ก็แนะนำให้ติดตั้ง nvm และ nvm เองก็ใช้ curl | sh เหมือนกัน สุดท้ายแนวทางผ่าน npm ก็เลยมีปัญหาเดียวกันทางอ้อม

    • ในการถกกันว่า npm install -g deno ปลอดภัยกว่า curl | sh จริงหรือไม่ ประเด็นสำคัญอยู่ที่ว่า "ระหว่างเซิร์ฟเวอร์ npm กับเซิร์ฟเวอร์ของโครงการเอง แฮ็กเกอร์จะเจาะที่ไหนได้ง่ายกว่ากัน?" ถ้ามั่นใจได้ว่าไม่ใช่การเจาะเซิร์ฟเวอร์ของโครงการเอง ก็ไม่มีเหตุผลว่าทำไม curl | sh จะต้องปลอดภัยน้อยกว่า npm install สุดท้ายจากมุมมองความปลอดภัย ทั้งสองวิธีก็อาจเปราะบางได้พอ ๆ กัน และถ้ามองแบบสุดโต่ง ปัญหาอาจอยู่ที่การใช้อินเทอร์เน็ตตั้งแต่แรก

    • มีคำวิจารณ์ว่า sandbox ของ Deno ให้ความรู้สึกเหมือนเทคโนโลยียุค 90 และการใช้งานมันเองก็ไม่ใช่นิสัยด้านความปลอดภัยที่ดีนัก

    • มีคนสงสัยว่าจริง ๆ แล้วเคยมีกรณีโจมตีแบบติดตั้งผ่าน curl | sh ที่สำเร็จในสถานการณ์จริงหรือไม่