Node.js 26.5.0 ഇപ്പോൾ ലഭ്യമാണ്. ഇതൊരു Current റിലീസാണ്, LTS ബ്രാഞ്ച് അല്ല, അതിനാൽ പ്ലാറ്റ്‌ഫോമിന് എന്തുചെയ്യാൻ കഴിയുമെന്നതിന്റെ മുൻനിരയിലാണ് ഇത് നിൽക്കുന്നത്. ആ വ്യത്യാസം പ്രധാനമാണ്. പതിനെട്ട് മാസത്തെ സ്ഥിരത പ്രതീക്ഷിക്കുന്ന ഒരു പ്രൊഡക്ഷൻ ഫ്ലീറ്റിലേക്ക് ഇത് അന്ധമായി മാറ്റരുത്. എന്നാൽ ഈ ചെറിയ, വേഗത്തിലുള്ള റിലീസുകളാണ് ഭാവി രൂപപ്പെടുന്നത് എവിടെയാണെന്ന് നിരീക്ഷിക്കേണ്ട ഇടം. മെയിന്റൈനർമാർ ഏത് API ആണ് കൂടുതൽ മെച്ചപ്പെടുത്തുന്നത് എന്നും റൺടൈം അടുത്തതായി എങ്ങോട്ടാണ് നീങ്ങുന്നത് എന്നും ഇവ കാണിച്ചുതരുന്നു. 26.5.0-ൽ, പ്രധാനപ്പെട്ട മാറ്റങ്ങൾ Web Streams API-യിലാണ്, ബ്രൗസറുമായി കൂടുതൽ സാമ്യം (parity) കൊണ്ടുവരുന്നതിനായി ചില പ്രത്യേക പരിഹാരങ്ങളോടെയാണ് ഇത് വരുന്നത്. ഫയൽ സിസ്റ്റം, URL ഹാൻഡ്‌ലിംഗ് ലെയറുകളിലെ രണ്ട് പ്രശ്നങ്ങളും ഈ റിലീസ് പരിഹരിക്കുന്നു.

Node.js-ൽ Web Streams എന്ത് ചെയ്യുന്നു?

നിങ്ങൾ കുറച്ചുകാലമായി Node-ൽ സ്ട്രീമിംഗ് കോഡ് എഴുതുന്നുണ്ടെങ്കിൽ, ഇൻബിൽറ്റ് stream മോഡ്യൂളിന് അതിന്റേതായ സവിശേഷതകളുണ്ടെന്ന് നിങ്ങൾക്കറിയാം. Readable, Writable, Transform, പിന്നെ Duplex എന്നിവ വർഷങ്ങളായി ഈ ഇക്കോസിസ്റ്റത്തിന്റെ കരുത്താണ്. അവ ശക്തമാണ്, പക്ഷേ ബ്രൗസറിൽ കാണുന്ന സ്ട്രീമുകൾ പോലെയല്ല അവ. ഒരു ഫ്രണ്ട്-എൻഡ് സർവീസ് വർക്കറും ബാക്ക്-എൻഡ് റൂട്ട് ഹാൻഡ്‌ലറും തമ്മിൽ ലോജിക് പങ്കിടാൻ ശ്രമിക്കുമ്പോൾ, ആ വ്യത്യാസം തടസ്സമായി മാറുന്നു. ഇതിനെത്തുടർന്ന് നിങ്ങൾ അഡാപ്റ്ററുകൾ വീണ്ടും എഴുതുകയോ, ഡാറ്റ അപരിചിതമായ രൂപങ്ങളിലേക്ക് പകർതുകയോ, അല്ലെങ്കിൽ പങ്കിട്ട കോഡ് പൂർണ്ണമായും ഒഴിവാക്കുകയോ ചെയ്യുന്നു.

ആ വിടവ് നികത്താനാണ് Web Streams API നിലവിലുള്ളത്. ബ്രൗസറിലെ fetch ബോഡി ഹാൻഡ്‌ലിംഗിന് ഉപയോഗിക്കുന്ന അതേ സ്റ്റാൻഡേർഡ് ആണിത്. ഇത് Node-ലേക്ക് കൊണ്ടുവരുന്നതിലൂടെ, സ്ട്രീമിംഗ് ലോജിക് ഒരിക്കൽ മാത്രം എഴുതി രണ്ട് എൻവയോൺമെന്റുകളിലും പ്രവർത്തിപ്പിക്കാൻ പ്രോജക്റ്റ് നിങ്ങളെ അനുവദിക്കുന്നു. ഈ API ReadableStream, WritableStream, TransformStream എന്നീ ഒബ്ജക്റ്റുകൾ വഴിയാണ് പ്രവർത്തിക്കുന്നത്. പതിപ്പ് 26.5.0 ആ ഇന്റർഫേസിനെ മാറ്റുന്നില്ല, പകരം രണ്ട് പ്രധാന കാര്യങ്ങൾ കൂടുതൽ കൃത്യതയുള്ളതാക്കുന്നു.

releaseLock പരിഹരിക്കലും BYOB Readers ക്ലീൻ അപ്പ് ചെയ്യലും

ഈ റിലീസിലെ ഒരു പ്രധാന മാറ്റം WritableStreamDefaultWriter-ലെ releaseLock മെത്തേഡിനുള്ള പരിഹാരമാണ്. Web Streams മോഡലിൽ, ഒരു റൈറ്റർ ലോക്ക് (writer lock) ഒന്നിലധികം കൺസ്യൂമർമാർ ഒരേസമയം ഒരേ സ്ട്രീമിൽ ഇടപെടുന്നത് തടയുന്നു. നിങ്ങൾ releaseLock() വിളിക്കുമ്പോൾ, നിങ്ങളുടെ റൈറ്റർ ജോലി പൂർത്തിയാക്കിയെന്നും അടിസ്ഥാന സ്ട്രീം അടുത്ത ഓപ്പറേഷനായി സ്വതന്ത്രമാണെന്നും നിങ്ങൾ അറിയിക്കുന്നു. ഇതിലെ പിശകുകൾ സ്ട്രീമിനെ ഒരു അവ്യക്തമായ അവസ്ഥയിൽ (limbo) എത്തിക്കാം; റൈറ്റർ പോയിക്കഴിഞ്ഞാലും സ്ട്രീം ഇപ്പോഴും ഉടമസ്ഥതയിലാണെന്ന് കരുതിയിരിക്കാം. അപ്‌ലോഡുകൾ പാഴ്സ് ചെയ്യുന്നതോ ഡാറ്റ സ്റ്റോറേജ്‌ലേക്ക് പൈപ്പ് ചെയ്യുന്നതോ ആയ തിരക്കുള്ള ഒരു സെർവറിൽ, ഇത്തരം സ്റ്റേൽ ലോക്കുകൾ (stale locks) പൈപ്പ്‌ലൈനിനെ തടസ്സപ്പെടുത്തുകയോ അല്ലെങ്കിൽ കണ്ടെത്താൻ പ്രയാസമുള്ള എററുകൾ ഉണ്ടാക്കുകയോ ചെയ്യാം. 26.5.0-ലെ പരിഹാരം ഈ കൈമാറ്റം (handoff) വീണ്ടും പ്രവചിക്കാവുന്നതാക്കുന്നു.

രണ്ടാമത്തെ Web Streams മാറ്റം ReadableStream, TransformStream എന്നിവ BYOB റീഡർമാരുമായി (BYOB readers) എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെ മെച്ചപ്പെടുത്തുന്നു. BYOB എന്നാൽ Bring Your Own Buffer എന്നാണ് അർത്ഥം. ഓരോ തവണ ഡാറ്റ നൽകുമ്പോഴും സ്ട്രീം പുതിയൊരു മെമ്മറി ഭാഗം (chunk) അനുവദിക്കുന്നതിന് പകരം, നിങ്ങൾ നേരത്തെ മാറ്റിവെച്ച ഒരു ബഫർ അതിന് നൽകുന്നു. സ്ട്രീം ആ ബഫർ നിറയ്ക്കുന്നു, നിങ്ങൾ ബൈറ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നു, തുടർന്ന് അതേ ബഫർ വീണ്ടും ഉപയോഗിക്കാനായി തിരികെ നൽകുന്നു. വലിയ അളവിൽ ഡാറ്റ കൈകാര്യം ചെയ്യുമ്പോൾ വലിയ ഫലം നൽകുന്ന ചെറിയൊരു സാങ്കേതിക മാറ്റമാണിത്.

Node-ൽ കുറച്ചുകാലമായി BYOB സപ്പോർട്ട് ഉണ്ടെങ്കിലും, ReadableStream, TransformStream എന്നിവയിൽ BYOB റീഡർ ഘടിപ്പിക്കുമ്പോൾ ചില പ്രത്യേക സാഹചര്യങ്ങളിൽ (edge cases) പ്രശ്നങ്ങൾ ഉണ്ടായേക്കാം. ഈ പരിഹാരത്തിന്റെ സാങ്കേതിക വശങ്ങളേക്കാൾ അതിന്റെ പ്രായോഗിക ഫലമാണ് പ്രധാനം: ബഫറുകൾ ഉപയോഗിക്കുന്ന സ്ട്രീമുകൾ ഇപ്പോൾ റീഡിംഗ്, ട്രാൻസ്ഫോർമേഷൻ ഘട്ടങ്ങളിൽ കൂടുതൽ വിശ്വസനീയമാണ്. ബാക്ക്പ്രഷർ (backpressure) സംഭവിക്കുമ്പോൾ ഉണ്ടാകുന്ന വിചിത്രമായ എററുകൾ കാരണം നിങ്ങൾ BYOB റീഡറുകൾ ഒഴിവാക്കിയിട്ടുണ്ടെങ്കിൽ, അവ ഒഴിവാക്കാനുള്ള ഒരു കാരണം കൂടി ഈ റിലീസ് ഇല്ലാതാക്കുന്നു.

BYOB യഥാർത്ഥത്തിൽ എവിടെയാണ് ഉപയോഗപ്പെടുന്നത്?

ബഫർ പുനരുപയോഗത്തെക്കുറിച്ച് (buffer reuse) പൊതുവായി സംസാരിക്കാൻ എളുപ്പമാണ്. എന്നാൽ അത് എവിടെയാണ് പ്രസക്തമെന്ന് ചിന്തിക്കുന്നത് കൂടുതൽ ഉപകാരപ്രദമാണ്.

ടെലിമെട്രി അപ്‌ലോഡുകൾ സ്വീകരിക്കുന്ന ഒരു സർവീസ് നിങ്ങൾ നിർമ്മിക്കുകയാണെന്ന് സങ്കൽപ്പിക്കുക. ആ അപ്‌ലോഡുകൾ കംപ്രസ് ചെയ്ത ലോഗുകളോ അല്ലെങ്കിൽ റോ സെൻസർ ഡമ്പുകളോ ആകാം, അവ ഓരോന്നും നൂറുകണക്കിന് മെഗാബൈറ്റുകൾ വലിപ്പമുള്ളവയാകാം. ഓരോ ഡാറ്റാ സ്ലൈസിനും സ്ട്രീം പുതിയൊരു Node Buffer അനുവദിക്കുകയാണെങ്കിൽ, ഗാർബേജ് കളക്ടർ (garbage collector) അമിതമായി ജോലി ചെയ്യേണ്ടി വരികയും മെമ്മറി ഉപയോഗം വേഗത്തിൽ വർദ്ധിക്കുകയും ചെയ്യും. BYOB റീഡർ ഉപയോഗിക്കുമ്പോൾ, സ്റ്റാർട്ടപ്പിൽ തന്നെ നിങ്ങൾ കുറച്ച് ബഫറുകളുടെ ഒരു പൂൾ (pool) മാറ്റിവെക്കുന്നു. സ്ട്രീം അവ നിറയ്ക്കുന്നു, നിങ്ങളുടെ പാഴ്സർ അവ ഉപയോഗിക്കുന്നു, അവ വീണ്ടും ഉപയോഗത്തിനായി തിരിച്ചെത്തുന്നു. മെമ്മറി ഉപയോഗം സ്ഥിരമായി നിലനിൽക്കുന്നു. രണ്ട് സോക്കറ്റുകൾക്കിടയിൽ നെറ്റ്‌വർക്ക് ട്രാഫിക് പ്രോക്സി ചെയ്യുമ്പോഴോ അല്ലെങ്കിൽ വലിയ CSV ഫയലുകൾ മുഴുവനായി RAM-ലേക്ക് ലോഡ് ചെയ്യാതെ വരിവരിയായി പാഴ്സ് ചെയ്യുമ്പോഴോ ഇതേ രീതി തന്നെ ഉപയോഗിക്കാം.

Transform streams are equally important here. A TransformStream sits in the middle of a pipeline, perhaps decompressing a gzip stream or encrypting chunks on the fly. If the transform step mishandles BYOB buffers, you can see corrupted output, dropped chunks, or stalls under load. The 26.5.0 fixes address exactly those kinds of pipeline hiccups, which is why anyone running high-throughput I/O should pay attention.

The Quiet Wins: File System and Error Clarity

Not everything in 26.5.0 is about streaming. The release also fixes behavior in fs.rm and fs.rmSync when the recursive option is set to false. Previously, passing recursive: false alongside a directory path could produce unexpected results during cleanup. The method might act in ways that did not match the explicit intent of the caller, deleting more than expected or failing in inconsistent ways depending on the platform. Cleaning up files is the sort of operation that should be boring and predictable. Boring is good. This fix restores that predictability, so your temporary directory cleanup scripts or deployment teardown logic behave exactly as the code suggests.

There is also a quality-of-life improvement in how URL.canParse reports failure. The method checks whether a string is a valid URL without throwing on malformed input. In 26.5.0, it now carries better Error.cause information when something goes wrong. Rather than swallowing the original reason, the error object preserves a causal chain. That means when a URL parse fails deep inside a validation helper, the stack you log tells you whether the issue was a bad protocol, a missing hostname, or some other structural problem. You spend less time sprinkling manual debug logs across every call site.

Should You Upgrade?

The answer depends on what you are running.

If your production workloads sit on an LTS version such as the v20.x line, stay there. These fixes will eventually backport or arrive in the next active LTS. Stability and predictable support timelines outweigh the benefit of a slightly smoother stream lock or clearer URL error on a server that is already working.

If you are building a new service, prototyping a real-time data pipeline, or actively using the Web Streams API for performance-critical I/O, 26.5.0 is worth the jump. The incremental alignment between Node streams and browser Web Streams is not just a compatibility win. It is a bet on a more unified JavaScript runtime where the same data-pushing logic can travel between server and client without translation layers. That cuts down on cognitive load and reduces the surface area for bugs when your team ships code to both environments.

This release is small, but the direction is clear. Node is continuing to invest in standards-based APIs that work everywhere JavaScript runs. The Web Streams improvements are not headline features, but they smooth out a path that has been rocky for years. Grab 26.5.0 if you live on the Current line, and watch for these fixes to land in your LTS world when the time is right.

Source: Dev.to – Node.js 26.5.0: What's New for Web Streams and Error Handling

Join the discussion and keep learning with the GyaanSetu community on Telegram.