लोकप्रिय npm पैकेजों की जगह लेने वाली नवीनतम Node.js बिल्ट-इन सुविधाएँ

• हाल के समय में Node.js तेज़ी से विकसित हो रहा है और जो फीचर पहले केवल npm पैकेजों से ही संभव थे, उन्हें अब रनटाइम में बिल्ट-इन कर रहा है
• इससे supply chain security जोखिम कम करना, कोड portability बढ़ाना, dependencies घटाना, और maintenance सरल बनाना संभव होता है, साथ ही production environment में performance और stability सुनिश्चित करने में मदद मिलती है
• fetch(), WebSocket, node:test जैसे global API जुड़ने से अब node-fetch, ws, mocha जैसे प्रसिद्ध पैकेजों के बिना भी development संभव है
• file system फीचरों के विस्तार से glob, rimraf, mkdirp की जगह fs.glob(), fs.rm(), fs.mkdir() options उपलब्ध हैं
• utility और cryptography API में crypto.randomUUID(), util.styleText(), atob/btoa आदि standard रूप में शामिल हैं, इसलिए uuid, chalk जैसे पैकेज अनावश्यक हो जाते हैं
• कुछ फीचर (node:sqlite, URLPattern, --env-file, TypeScript execution आदि) अभी भी experimental चरण में हैं
• महत्वपूर्ण बात यह है कि Node.js के अपने विकास के कारण अब सिर्फ़ बेस runtime से भी modern application development संभव हो गया है

---

Node.js की बिल्ट-इन सुविधाओं से बदले गए प्रमुख npm पैकेज

• अब तक Node.js HTTP utilities, file system helpers आदि के लिए कई npm पैकेजों पर निर्भर रहा है
• लेकिन हाल के versions (v18~v22) में इन क्षमताओं को धीरे-धीरे सीधे runtime में integrate करने की प्रवृत्ति मज़बूत हुई है
• इससे package management की जटिलता और security exposure का जोखिम कम होता है

1. node-fetch → Global fetch()

• Node.js 18 से browser जैसा ही fetch() global function के रूप में उपलब्ध है
• node-fetch के बिना भी HTTP requests को handle किया जा सकता है
• v17.5.0 में experimental रूप से जोड़ा गया था और v18.0.0 में stable हुआ
• हालांकि 18 से पहले के versions में अब भी node-fetch की ज़रूरत है

2. ws → Global WebSocket

• Node.js 21 से global WebSocket class के ज़रिए client-side WebSocket connection का समर्थन मिलता है
  • v21.0.0 में experimental रूप से जोड़ा गया, और अभी तक experimental चरण में है
• server-side WebSocket implementation के लिए अब भी ws पैकेज या संबंधित libraries की ज़रूरत है

3. टेस्ट फ्रेमवर्क → node:test

• Node.js 18 से mocha, jest आदि की जगह लेने वाला बिल्ट-इन test runner node:test उपलब्ध है
  • v18.0.0 में experimental रूप से पेश किया गया, v20.0.0 में stable हुआ
  • बुनियादी unit tests लिखने और चलाने का समर्थन देता है
• अगर snapshot, mocking, समृद्ध plugins आदि चाहिए हों, तो third-party frameworks अब भी उपयोगी हैं
  • module-level testing के लिए पर्याप्त है, लेकिन full-stack application development में पारंपरिक frameworks के अपने फायदे बने हुए हैं

4. sqlite3 / better-sqlite3 → node:sqlite

• Node.js में SQLite access के लिए experimental node:sqlite module लाया जा रहा है
  • मौजूदा native binding पैकेजों की compilation समस्याओं और upgrade के समय आने वाली त्रुटियों को हल करने में मदद
  • in-memory database बनाना, table creation जैसी बुनियादी operations का समर्थन
• चूँकि यह अभी experimental है, इसलिए advanced performance tuning या अतिरिक्त फीचरों की ज़रूरत हो तो community पैकेजों का उपयोग करना उचित है

5. chalk / kleur → util.styleText()

• Node.js 20.12.0 से util.styleText() के ज़रिए console text styling संभव है
  • v22.17.0 में stable हुआ
  • color, bold, underline जैसे बुनियादी text styles लागू किए जा सकते हैं
• अगर जटिल themes, chaining syntax, backward compatibility चाहिए, तो chalk आदि का उपयोग जारी रखा जा सकता है

6. strip-ansi → util.stripVTControlCharacters()

• ANSI escape codes हटाने की सुविधा Node.js बिल्ट-इन function के रूप में उपलब्ध है
  • logs से control characters को सुरक्षित रूप से हटाया जा सकता है
• ज़्यादातर उपयोग मामलों को native रूप से कवर कर लेने के कारण third-party पैकेज की ज़रूरत नहीं रहती

7. glob → fs.glob()

• Node.js 22 से file pattern search के लिए बिल्ट-इन fs.glob() फीचर जोड़ा गया है
  • v22.0.0 में जोड़ा गया, v22.17.0 LTS में stable हुआ
  • **/*.js जैसे glob patterns से फ़ाइलें खोजी जा सकती हैं
• अगर पुराने Node.js versions के साथ compatibility चाहिए, तो glob पैकेज का उपयोग करें

8. rimraf → fs.rm({ recursive: true })

• directory को recursively delete करने का समर्थन Node.js native API में है
  • fs.rm() के recursive, force options से इसे लागू किया जा सकता है
  • v12.10.0 के आसपास से उपलब्ध, और अब सभी LTS versions में stable है
• rimraf पैकेज के बिना भी सुरक्षित directory deletion संभव है

9. mkdirp → fs.mkdir({ recursive: true })

• directory को recursively create करने की सुविधा fs.mkdir() के recursive option से मिलती है
  • v10.12.0 से उपलब्ध और लंबे समय से stable है
• अलग पैकेज के बिना nested directories बनाई जा सकती हैं

10. uuid → crypto.randomUUID()

• Node.js 14.17.0 से UUID generation function crypto.randomUUID() उपलब्ध है
  • cryptography module की stable capability के रूप में शामिल
• uuid पैकेज के बिना सुरक्षित random ID बनाई जा सकती है

11. base64-js / atob → atob, btoa

• Node.js 20 से atob, btoa global functions उपलब्ध हैं
  • browser जैसे ही Base64 encoding/decoding API
  • मौजूदा Buffer के अलावा अतिरिक्त विकल्प प्रदान करते हैं
• polyfill के बिना Base64 processing संभव है

12. url-pattern → URLPattern

• Node.js 20 से global URLPattern API experimental रूप से उपलब्ध है
  • route matching, path parameter extraction आदि का समर्थन
  • अभी experimental चरण में है, इसलिए stabilization की ज़रूरत है
• URL pattern matching को standard Web API से handle किया जा सकता है

13. dotenv → --env-file फ्लैग

• Node.js 20.10.0 से --env-file फ्लैग के ज़रिए environment variables लोड किए जा सकते हैं
  • execution के समय .env फ़ाइल सीधे लोड की जा सकती है
  • अभी experimental चरण में है
• variable expansion, multiple env files जैसे advanced फीचरों के लिए dotenv पैकेज अब भी ज़रूरी है

14. event-target-shim → EventTarget

• Node.js 15.0.0 से Web standard EventTarget event system global रूप में उपलब्ध है
  • v15.4.0 में stable हुआ
  • browser जैसा event handling model समर्थित है
• इसे EventEmitter के विकल्प के रूप में इस्तेमाल किया जा सकता है

15. tsc → Node.js TypeScript execution

• Node.js 21 से --experimental-strip-types फ्लैग के साथ .ts फ़ाइलें सीधे चलाना संभव है
  • यह केवल types हटाता है, full type checking का समर्थन नहीं करता
  • अभी experimental चरण में है
• production build, static type checking, declaration file generation, complete type checking के लिए tsc अब भी आवश्यक है

निष्कर्ष

• Node.js की विकास दिशा external पैकेज dependencies कम करने और platform की अपनी पूर्णता बढ़ाने की ओर है
• नवीनतम LTS version (v22) में कई npm पैकेज पहले ही अनावश्यक हो चुके हैं,
  और इसका अर्थ security, performance, और maintainability के लिहाज़ से बड़ा सुधार है
• enterprise operating environments में इन बदलावों को real time में monitor करने के लिए N|Solid जैसे solutions का उपयोग किया जा रहा है
  • बिल्ट-इन फीचरों (fetch, node:test, crypto.randomUUID() आदि) के वास्तविक workload performance का analysis
  • N|Sentinel AI agent usage monitoring और code-level optimization recommendations प्रदान करता है

[nemorize]

runtime द्वारा दी जाने वाली APIs लगातार बढ़ती जा रही हैं..
खासकर network API, URL, b64 जैसी string processing APIs वगैरह...

ये तो पूरी तरह... PH..

[carnoxen]

लगता है कि Uuid v7 के लिए अभी थोड़ा जल्दी है।

[click]

मुझे लगता है कि db driver को उन फीचर्स से अलग नज़रिए से देखना चाहिए जो दूसरी standard libraries में होने चाहिए। bun भी ऐसा कर रहा है, लेकिन sqlite driver को runtime में built-in करने की वजह क्या है?
क्या इसलिए कि Python में यह built-in है?

मेरा मानना है कि sqlite फीचर को built-in करने के बजाय db driver interface का standard बनाना ज़्यादा महत्वपूर्ण है।
हर driver का interface अलग होता है, इसलिए अगर अलग-अलग तरह के db को support करना हो तो ORM के बिना यह मुश्किल नहीं हो जाता क्या?

[aer0700]

शायद इसे इसलिए जोड़ा गया है क्योंकि पर्सनल ब्लॉग जैसी छोटी सेवाओं के लिए अक्सर सिर्फ sqlite ही काफी होता है। हो तो सुविधाजनक रहता है।

[tujuc]

मेरा ख्याल है कि sqlite का interface सबसे सरल है और reference के तौर पर देखने के लिए भी सबसे अच्छा है, इसलिए शायद उसे शामिल किया गया होगा.

और आपने जो DB Driver interface standard की बात कही, वह क्यों बनाना चाहिए यह मुझे ठीक से समझ नहीं आ रहा. कुछ मिलता-जुलता मैंने शायद PHP में देखा था, ऐसी धुंधली-सी याद है.

ORM से handle न हो पाने वाली जटिल queries के लिए अभी भी RAW queries का इस्तेमाल हो रहा है...
लगता है आपको कई तरह के DB इस्तेमाल करने की ज़रूरत अक्सर पड़ती है... एक library बनाकर देखने के बारे में क्या ख़याल है? :)

[click]

python, java, c#, go आदि में ऐसे कई मामले काफ़ी आम हैं जहाँ runtime DB driver interface का standard बना देता है.
लेकिन Node में तो अभी एक ही sqlite target वाले drivers के बीच भी statement execution execute() या exec() के रूप में अलग-अलग होता है, इसलिए सिर्फ driver बदलने पर भी कुछ हद तक code में संशोधन करना पड़ता है.

यह बहुत अक्सर होने वाली बात नहीं है, लेकिन DB बदलने की स्थिति भी असुविधाजनक होती है.
मान लीजिए पहले mysql इस्तेमाल कर रहे थे, फिर Oracle जो कर रहा है वह पसंद नहीं आया, या PostgreSQL extensions में कोई ऐसी चीज़ चाहिए जो अनिवार्य हो, इसलिए PostgreSQL पर जाना पड़े
तो jdbc जैसी standard interface वाली स्थिति में सिर्फ SQL verify करना काफ़ी होता है, लेकिन Node ecosystem में DB call logic पूरा फिर से बदलना पड़ने का side effect है.

+लाइब्रेरी बनाने की सिफारिश की गई थी, लेकिन common interface standard हो तो लाइब्रेरी बनाते समय काफ़ी सुविधा होती है.
हमारी कंपनी Java इस्तेमाल करती है, और in-house framework में mysql, db2, oracle, mssql support करना पड़ता है, इसलिए DB-specific adapters की maintenance करते समय jdbc standard का बहुत फ़ायदा मिला.