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:
The documented filesystem LOB examples still use the unsupported
fstream@1.0.12package 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.jsimportsfstreamand callsfstream.Reader({ path: dirname, filter: isChildFile }), then pipes filesystem entries into the HANA statement adapter.examples/app6.jsimportsfstreamand createsnew fstream.Writer({ path: dirname, type: 'Directory' }), then pipes HANA LOB rows into the destination directory.package.jsondeclares the exact direct dev dependency"fstream": "1.0.12".One low-diff option would be an npm alias:
That would preserve both existing
require('fstream')calls and the Reader/Writer API. The expected repository changes would be limited topackage.json,package-lock.json, and any focused example coverage the maintainers request.@stackline/fstreamdeclares Node.js>=14.15.1;node-hdbdeclares 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
fsand 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.jsv20.20.2and npm10.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.jsorexamples/app6.js, and both examples require a configured HANA connection. If the alias option is welcome, I can prepare thepackage.json/package-lock.jsonchange 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 thenode-hdbmaintainers. This proposal is about dependency maintenance only. It is not a vulnerability report, makes no security claim aboutfstreamornode-hdb, and does not ask the project to treat it as a security fix.References: