Replace unsupported fstream in filesystem LOB examples

Nobody has claimed this yet.

The documented filesystem LOB examples still use the unsupported fstream@1.0.12 package as a direct development dependency. Would the maintainers prefer to replace that implementation through a compatibility alias, rewrite the examples with Node's built-in filesystem/stream APIs, or remove the dependency/examples if they are no longer supported?

The current uses are limited but real:

examples/app5.js imports fstream and calls fstream.Reader({ path: dirname, filter: isChildFile }), then pipes filesystem entries into the HANA statement adapter.
examples/app6.js imports fstream and creates new fstream.Writer({ path: dirname, type: 'Directory' }), then pipes HANA LOB rows into the destination directory.
Both examples are listed in the README's “Running examples” section.
package.json declares the exact direct dev dependency "fstream": "1.0.12".

One low-diff option would be an npm alias:

"fstream": "npm:@stackline/fstream@1.0.0"

That would preserve both existing require('fstream') calls and the Reader/Writer API. The expected repository changes would be limited to package.json, package-lock.json, and any focused example coverage the maintainers request. @stackline/fstream declares Node.js >=14.15.1; node-hdb declares Node.js >=18, and its workflow matrix lists Node.js 20, 22, 24, and 26.

The alternative is to replace the examples' fstream-specific entry handling with built-in fs and stream primitives, or remove these examples and the dependency if they are no longer maintained. That avoids adopting another package but is a larger behavioral rewrite. I do not have a preference over the project's desired maintenance direction.

Clean baseline recorded on 2026-08-28 at f26df559cdc9b01e7c5055f3b8571537cac4a4bf, using Node.js v20.20.2 and npm 10.8.2:

npm ci: exit 0; 138 packages added, 139 audited; npm emitted the existing fstream deprecation warning.
npm test: exit 0; 586 tests passed.

The unit suite does not exercise examples/app5.js or examples/app6.js, and both examples require a configured HANA connection. If the alias option is welcome, I can prepare the package.json/package-lock.json change and include any focused example coverage the maintainers request. It should preserve the clean unit baseline and add or document an isolated Reader/Writer smoke check where practical; end-to-end example validation would still require HANA.

Disclosure: I maintain @stackline/fstream, an independent compatibility-focused package. I am not affiliated with SAP or the node-hdb maintainers. This proposal is about dependency maintenance only. It is not a vulnerability report, makes no security claim about fstream or node-hdb, and does not ask the project to treat it as a security fix.

References:

Wait for the maintainers to choose between the alias, built-in filesystem APIs, or removing the examples. Then inspect package.json, package-lock.json, examples/app5.js, examples/app6.js, and the README's Running examples section; run npm test and validate any focused example coverage that is requested. Done means the selected direction is documented, the dependency and examples are consistent, and the existing unit suite remains green.

Written by the indexing model from the issue text.

Description

Contributor guide

First steps

Research direction

Assessment