Deno 2.4 रिलीज़

 (deno.com)
2 पॉइंट द्वारा GN⁺ 2025-07-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • deno bundle को esbuild-आधारित रूप में फिर से पेश किया गया है, जिससे सर्वर और ब्राउज़र दोनों के लिए सिंगल-फाइल बंडल बनाना और ऑटोमैटिक tree shaking व optimization संभव हो गया है
  • text/byte import सपोर्ट और built-in OpenTelemetry के stable होने जैसी चीज़ों से observability और external file उपयोग का अनुभव बेहतर हुआ है
  • नया --preload फ्लैग, dependency सुविधा को बेहतर बनाने वाला deno update, script coverage मापन, permission management और Node.js API compatibility तक व्यापक सुधार किए गए हैं
  • LSP, Jupyter, bench/coverage, tsconfig सपोर्ट में सुधार के साथ कई usability enhancements भी दिए गए हैं

Deno 2.4 के मुख्य बदलाव और नई सुविधाओं का सार

deno bundle की वापसी

  • Deno 2.4 में single-file JavaScript bundle बनाने वाला deno bundle subcommand esbuild इंजन के साथ फिर से जोड़ा गया है
  • यह सर्वर और ब्राउज़र दोनों को सपोर्ट करता है, और npm, JSR dependencies को भी बिना समस्या बंडल कर सकता है
  • ऑटोमैटिक tree shaking और code optimization (minify) सपोर्ट के साथ अधिक सुविधाजनक environment मिलता है
  • आगे चलकर runtime API और plugin के जरिए bundle process को programmatically extend और customize करने की सुविधा भी जोड़ी जाएगी

text और byte import सपोर्ट

  • JavaScript module graph में text, binary, image जैसी external data files को embed करने के लिए --unstable-raw-imports फ्लैग दिया गया है
  • पहले external files को file I/O के जरिए पढ़ना पड़ता था, लेकिन अब import syntax में file type बताकर सीधे byte/text data इस्तेमाल किया जा सकता है
  • यह फीचर bundling और compile के समय भी काम करता है, जिससे output में asset embedding आसान हो जाता है
  • JSON, Wasm जैसे मौजूदा import सपोर्ट के साथ कई file formats को spec-friendly तरीके से मैनेज किया जा सकता है
  • स्पेसिफिकेशन पर अभी चर्चा चल रही है, लेकिन Deno इस फीचर के विकास और standard trends के बीच संतुलन बनाए रख रहा है

built-in OpenTelemetry का stabilization

  • 2.2 version में जोड़ा गया built-in OpenTelemetry support 2.4 में पूरी तरह stable हो गया है
  • सिर्फ OTEL_DENO=1 environment variable सेट करने पर, बिना अलग फ्लैग के log, metric, trace collection ऑटोमैटिक हो सकती है
  • Node.js के साथ zero-config compatibility और Deno Deploy deployment environment तक एकसाथ सपोर्ट मिलता है
  • console.log logs और HTTP requests की automatic linking/observation भी संभव है
  • resource usage की प्रकृति को देखते हुए environment variable control की ज़रूरत है

execution से पहले environment setup के लिए --preload फ्लैग

  • मुख्य script चलने से पहले global environment बदलने, data loading, dependent module registration आदि के लिए code को पहले चलाने वाला --preload फ्लैग जोड़ा गया है
  • platform customization या global object reset जैसे कई तरह के platform setup में यह उपयोगी है
  • इसे deno run, deno test, deno bench जैसे प्रमुख commands में इस्तेमाल किया जा सकता है

dependency management आसान: deno update

  • npm और JSR dependencies को latest version पर auto-update करने के लिए deno update subcommand पेश किया गया है
  • कई dependencies को एक साथ अपडेट करना और Semver compatibility के आधार पर precise update करना संभव है
  • मौजूदा deno outdated --update का alias भी दिया गया है, जिससे usability बेहतर हुई है

script coverage: deno run --coverage

  • सिर्फ अलग-अलग tests ही नहीं, बल्कि subprocess शामिल पूरे execution की coverage भी इकट्ठी की जा सकती है
  • DENO_COVERAGE_DIR environment variable सहित कई तरीकों से flexible data management संभव है
  • HTML coverage report में dark mode सपोर्ट भी जोड़ा गया है

Deno compatibility environment variable DENO_COMPAT=1

  • npm ecosystem और package.json-आधारित projects की सुविधा और compatibility बढ़ाने के लिए DENO_COMPAT=1 variable जोड़ा गया है
  • यह कई unstable flags को अपने आप लागू करता है, और आगे चलकर npm prefix omission जैसी सुविधाएँ भी बढ़ाई जाएँगी

permission management और security सुधार

  • --allow-net फ्लैग में subdomain wildcard और CIDR range सपोर्ट जोड़ा गया है
  • code किन hosts से import कर सकता है, इसे सीमित करने वाला --allow-import और explicit block के लिए --deny-import फ्लैग नए जोड़े गए हैं
  • Deno.permissions API में "import" type query का आधिकारिक सपोर्ट दिया गया है
  • Deno.execPath() इस्तेमाल करते समय अब read permission की ज़रूरत नहीं है, जिससे executable path का उपयोग आसान हो गया है

conditional package.json exports

  • npm packages में conditional exports सपोर्ट जोड़ा गया है, खासकर React server configuration जैसे विभिन्न ecosystem scenarios के लिए
  • user condition flags के जरिए flexible custom import behavior लागू किया जा सकता है

deno run में bare specifier सपोर्ट

  • deno.json के "imports" में सेट किए गए alias (bare specifier) से command entrypoint चलाया जा सकता है
  • development productivity और module management automation के लिहाज़ से यह बड़ी सुविधा देता है

XML, SVG जैसे formats की code formatting में सुधार

  • deno fmt में .xml, .svg, .mustache जैसी कई template files के लिए automatic formatting सपोर्ट जोड़ा गया है

tsconfig.json सपोर्ट मजबूत

  • references, extends, files, include, exclude जैसे कई options को पहचानने की accuracy बेहतर हुई है
  • Vue, Svelte, Solid, Qwik जैसे आधुनिक frontend frameworks के साथ compatibility और बेहतर हुई है

Node global variables और API compatibility में वृद्धि

  • Buffer, global, setImmediate, clearImmediate जैसे Node.js global objects अब user code में भी हमेशा मौजूद रहेंगे
  • जो globals पहले केवल npm packages के लिए थे, वे अब बिना command flag के सीधे उपयोग किए जा सकते हैं
  • node:buffer, node:events, node:querystring, node:quic, node:wasm आदि में 95% से अधिक compatibility हासिल की गई है, और इसे आगे भी लगातार बढ़ाया जाएगा
  • @types/node type का default version भी 22.15.14 पर अपडेट किया गया है

local npm package management में बदलाव

  • npm local package linking option का नाम patch से बदलकर links कर दिया गया है, ताकि यह npm link के अर्थ से मेल खाए
  • पुराना option इस्तेमाल करने पर deprecation warning दी जाती है, जिससे package management अधिक स्पष्ट बनता है

LSP और development productivity सुधार

  • LSP performance और features में सुधार के साथ fetch के लिए Unix/Vsock socket सपोर्ट, server का onListen callback, Jupyter kernel management, lint plugins में comments पढ़ना और bench/coverage tables की Markdown compatibility जैसी कई सुविधाएँ दी गई हैं
  • Windows पर Ctrl+Close signal recognition (windows SIGHUP), bench/coverage text output का Markdown format आदि में भी नए सुधार किए गए हैं

community और contributors को धन्यवाद

  • Deno 2.4 के विकास में विभिन्न community contributors की भागीदारी और feedback ने बड़ी भूमिका निभाई है
  • अधिक जानकारी और विस्तृत बदलावों के लिए GitHub रिलीज़ पेज देखा जा सकता है

निष्कर्ष

  • Deno 2.4, bundling, external file import, observability, permission/security, compatibility, productivity जैसे कई क्षेत्रों में बड़ा सुधार लाता है
  • development workflow और आधुनिक frontend तथा Node ecosystem projects में आसान और शक्तिशाली integrated development environment जैसा अनुभव मिल सकता है
  • अतिरिक्त जानकारी, ताज़ा समाचार और पूरा change history आधिकारिक docs, blog और GitHub release page पर देखा जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2025-07-08
Hacker News टिप्पणियाँ

  • मुझे Deno का कॉन्सेप्ट सच में बहुत पसंद है, इसलिए मैंने Next.js, Hono, और private packages वाले एक monorepo प्रोजेक्ट में Deno.json, JSR, modern import, Deno Deploy वगैरह को जितना हो सके उतना अपनाने की कोशिश की थी। Hono साफ़-सुथरे तरीके से अच्छी तरह चला, लेकिन Next.js के साथ ऐसा नहीं था, और types से जुड़े issues भी हल्के-फुल्के तरीके से टूटते हुए मिले। deploy target (जैसे Vercel) चुनना भी एक समस्या थी। उदाहरण के तौर पर जो छोटी समस्या आई थी, उसे issue link में साझा किया था। दूसरी तरफ Bun, Deno जितना साफ़-सुथरा महसूस नहीं हुआ, लेकिन सोचने के लिए कम चीज़ें थीं और बस "चल जाता है" जैसी छाप थी। हालांकि Bun भी Vercel पर Bun runtime के unsupported होने जैसी वजहों से परफ़ेक्ट नहीं है

    • सलाह यह थी कि चुना गया stack अभी भी npm-केंद्रित है, खासकर ऐसे माहौल में जहाँ private npm packages बहुत हैं, इसलिए यह ज़रा ज़बरदस्ती जैसा था। मुझे लगता है Deno-स्टाइल अप्रोच का असली sweet spot अपने-आप में Deno या ESM-friendly stack चुनने में है। Lume इस्तेमाल करने या Deno Deploy को target करने का अनुभव अच्छा था। (JSR score की वजह से दिलचस्प और मज़बूत ESM compatibility वाली libraries खोजने में भी मदद मिली।) बेशक, पूरी तरह नए stack से शुरू करो कहना व्यावहारिक नहीं है, और Next.js जैसी मौजूदा investments भी बड़ी हैं, इसलिए Deno की सिफारिश करना बोझिल लगता है। लेकिन Deno की ताकत वहीं दिखती है जहाँ आप Deno-native, ESM-native tools के पूरे सेट के साथ 0 से शुरू कर रहे हों। वैसे Deno की npm compatibility लगातार बेहतर हो रही है, और 2.4 release notes में भी इससे जुड़े improvements हैं। full-stack environment में deno.json के बजाय package.json-first approach वास्तव में ज़्यादा compatible हो सकती है, इसलिए लंबे समय में deno.json की तरफ बढ़ते हुए भी package json-आधारित setup की सिफारिश है

    • npm compatibility mode में Deno चलाकर देखा तो उम्मीद से बेहतर काम करता लगा। इस्तेमाल का तरीका Bun से काफी मिलता-जुलता है। package.json वाले directory में deno install चलाने पर यह slim node_modules बना देता है, और deno task something कमांड से package.json में defined scripts भी चला सकते हैं। लेकिन Deno-के-अपने तरीके में अक्सर बहुत समय लगता था, जिससे झुंझलाहट हुई, और फिर वापस node/npm environment में जाना चाहो तो सिरदर्द और बढ़ जाता है। निष्कर्ष यह कि package.json के साथ Deno इस्तेमाल करना ज़्यादा आसान है

    • शुरू में मैं Deno पर पूरी तरह गया था, लेकिन छोटी-छोटी समस्याएँ इतनी ज़्यादा थीं कि मुश्किल हो गया। उसके मुकाबले Bun बिना ज़्यादा ध्यान दिए ठीक से चल जाता है

  • लोग Deno की node compatibility को कम आँकते हैं। उम्मीद है compat environment variable अपनाए जाने से इसका प्रसार बढ़ेगा। अगर denon जैसे commands इसे अपने-आप चालू कर दें तो और सुविधाजनक होगा

    • मेरे अनुभव में Deno की node compatibility उम्मीद से कमज़ोर रही, जो निराशाजनक था। करीब 100~200 lines के एक साधारण प्रोजेक्ट को Deno में migrate करने में लगभग 1 घंटा लगा, जबकि वास्तव में यह 5~10 मिनट में हो जाना चाहिए था। node के कुछ methods supported नहीं थे, उनसे जुड़ी docs भी कमज़ोर थीं, और basic functionality भी किसी obscure URL से सीधे डाउनलोड करनी पड़ती थी। test suite port करते समय तो आखिरकार हार माननी पड़ी। खासकर CommonJS(CJS) से ESM में migration उम्मीद से कहीं ज़्यादा दर्दनाक था, और Deno के official docs जितना आसान बताते हैं, उतना बिल्कुल नहीं था। पूरी library को port ही नहीं कर सका

    • पहले मैं Deno को लेकर काफ़ी सकारात्मक था, लेकिन अब मुझे खास वजह नहीं दिखती कि Bun की जगह Deno क्यों इस्तेमाल करूँ

  • Deno के हालिया changes की list अच्छी लगी। मैं random scripts / glue code लिखने के लिए Deno से संतुष्ट हूँ (machine learning वगैरह के लिए python/uv इस्तेमाल करता हूँ), और आगे gRPC support और bundle command से भी उम्मीद है

  • यह अभी भी अजीब लगता है कि Deno FreeBSD पर ठीक से काम नहीं करता। Rust-आधारित V8 bindings अभी तक port नहीं हुई हैं

    • सोचता हूँ कि आज के modern JavaScript developers में FreeBSD users वास्तव में कितने होंगे

    • पहले Unix के बीच portability को code की साफ़-सफ़ाई का पैमाना माना जाता था, लेकिन आजकल अलग-अलग Unix systems के बीच compatibility पर इतना ज़ोर नहीं दिया जाता, यह थोड़ा अजीब लगता है

    • लगता है कि FreeBSD ports में यह registered है

    • FreeBSD support पर ज़्यादा मेहनत न करने की वजह काफ़ी हद तक समझ में आती है

  • एक राय यह है कि Deno production में ज़्यादा व्यापक रूप से इसलिए इस्तेमाल नहीं होता क्योंकि standardized vulnerability DB नहीं है। npm के साथ 100% compatibility से इसकी कुछ भरपाई हो सकती है, लेकिन तब ज़्यादातर लोकप्रिय deno packages दायरे से बाहर हो जाते हैं। मूल रूप से central package manager का न होना (जो जानबूझकर किया गया design है) एक चुनौती है। पूछा गया कि क्या इस दिशा में कोई प्रगति हुई है

    • जवाब में कहा गया कि अगर vulnerability DB की कमी production में सचमुच बड़ी समस्या है, तो C/C++ भी इस्तेमाल नहीं किए जा सकते। व्यवहार में C/C++ के लिए language-neutral CVE/GHSA DB जैसी चीज़ें देखकर security issues ट्रैक किए जाते हैं। वैसे C में तो कई बार लोग बस external files vendor करके इस्तेमाल करते हैं और version tracking भी नहीं रखते। साथ ही deno.lock फ़ाइल मौजूद है, इसलिए जो लोग ध्यान देते हैं, वे इसमें दर्ज versions के आधार पर vulnerability DB चेक कर सकते हैं

    • GitHub जैसी URL से सीधे packages लाने का ढाँचा Go में भी मिलता-जुलता है, इसलिए वही issue Go पर भी लागू होगा

  • bundle subcommand का फिर से जोड़ा जाना अच्छा लगा। अब झंझट वाले workaround की ज़रूरत नहीं रही

  • यह थोड़ा surprising है कि bundling के लिए Rust-आधारित Rolldown की जगह esbuild चुना गया। Rolldown तो अब जल्द ही v1 में आने वाला है

    • esbuild इस समय बहुत stable और mature है, जबकि Rolldown अभी भी तेज़ी से बदल रहा है, इसलिए esbuild चुनना ज़्यादा सुरक्षित विकल्प है

  • Deno की दिशा मुझे सच में पसंद है, और लगता है Node को मूल रूप से ऐसा ही होना चाहिए था। लेकिन चिंता यह है कि कहीं competitors के 'hype' में बहकर Deno भी बिना सोचे-समझे उसी दिशा में न बदल जाए

    • हो सकता है Deno खुद भी अब तक Node.js के एक 'hype'-driven competitor के रूप में देखा गया हो

  • मैं Deno के बारे में लगातार अच्छी बातें सुन रहा हूँ। इसकी वजह से अब सोचने लगा हूँ कि शायद js एक बार आज़माना चाहिए

    • आज के समय में शुरुआत से ही TS चुनना भी बुरा विकल्प नहीं है

  • security के नज़रिए से मैं Deno का समर्थन करता हूँ, लेकिन official site पर users को curl mywebsite.com/foo.sh | sh स्टाइल installation सुझाया जाना मुझे असहज लगा था। जोखिम सहने का स्तर सबका अलग हो सकता है, लेकिन कम-से-कम अगर फ़ाइल डाउनलोड करके चलाओ तो आप या antivirus उसे देख सकते हैं। Node/Deno + npm ecosystem मूल रूप से काफ़ी trust माँगता है। official guide में curl | sh के अलावा npm install -g deno विकल्प भी दिया गया है, और npm में कम-से-कम basic file integrity checks और साधारण malware scanning तो होती है, इसलिए वह तुलनात्मक रूप से सुरक्षित लगता है। deno.land वेबसाइट codebase के स्तर पर सुरक्षित हो सकती है, लेकिन operations के स्तर पर 100% गारंटी नहीं दी जा सकती, इसलिए curl | sh को security best practice नहीं मानता

    • इस तर्क से असहमति जताई गई। ज़्यादातर install scripts आखिरकार उसी लेखक द्वारा बनाए गए सैकड़ों से लेकर लाखों lines वाले binaries डाउनलोड करके चलाती हैं। अगर आप लेखक पर इतना भी भरोसा नहीं करते कि आपको यह डर हो कि server कुछ खास IPs को malware दे सकता है, तो फिर binary स्तर पर भी malware डाला जा सकता है, और ऐसे में आपको वह project ही इस्तेमाल नहीं करना चाहिए। शायद curl | sh वाली बहस इसलिए फैली क्योंकि यह एक आसान और बार-बार दोहराई जाने वाली दलील है, जबकि असली security issue तो लाखों lines के code review का है। अगर चिंता government-level MITM attack तक जाती है, तो फिर इंटरनेट से आने वाले बाहरी trust को ही छोड़ना पड़ेगा

    • नए users की onboarding में दिक्कत होने की बात भी उठी। अगर npm इस्तेमाल करने की सलाह दें तो पहले npm installed होना चाहिए, लेकिन npm की official site nvm install करने को कहती है, और nvm भी curl | sh इस्तेमाल करता है। इसलिए npm वाला रास्ता भी परोक्ष रूप से उसी समस्या तक पहुँचता है

    • npm install -g deno वास्तव में curl | sh से ज़्यादा सुरक्षित है या नहीं, इस चर्चा में मुख्य सवाल यह था: "npm server और अपने server में से किसे hacker के लिए compromise करना आसान है?" अगर आपको यक़ीन है कि अपना server compromise नहीं हुआ, तो curl | sh के npm install से कम सुरक्षित होने की कोई सीधी वजह नहीं है। आख़िरकार security के लिहाज़ से दोनों तरीके समान रूप से vulnerable हो सकते हैं, इसलिए बहुत चरम नज़रिए से देखें तो समस्या इंटरनेट इस्तेमाल करने में ही है

    • Deno के sandbox implementation को 90s-era technology जैसा बताते हुए, उसके इस्तेमाल को अच्छी security habit नहीं माना गया

    • जिज्ञासा जताई गई कि क्या curl | sh installation method पर सफल real-world attacks के उदाहरण मौजूद हैं