Repository navigation
fs.createWriteStream TypeError with new io.js v2.3.0 #1981
Description
Activity
I will test this later today.
It is indeed related to 353e26e.
karma-html-reporteris using fs.createWriteStream with a callback, which is not supported and AFAIK has never been. This sudden error is uncovering a bug that needs to be fixed in the module.True.
https://iojs.org/api/fs.html#fs_fs_createwritestream_path_options says nothing about callbacks, so that's not supported.Yep, they should fix this bug with
closeevent.Still, it might be sensible to add a work-around for that on the io.js side.
Some other places:
g/gist-backup-1.0.0.tgz/gist-backup.js: request(raw_url).pipe(fs.createWriteStream(dir + '/' + filename, function (error) { m/mecano-0.4.1.tgz/lib/download.js: return fs.createWriteStream(null, stageDestination, function(err, ws) { m/mecano-0.4.1.tgz/lib/download.js: return fs.createWriteStream(null, stageDestination, function(err, ws) { m/mecano-0.4.1.tgz/lib/upload.js: return fs.createWriteStream(options.ssh, options.destination, function(err, ws) {mecano is not using the
fsmodule, butssh2-fsinstead. This library seems to accept a callback in createWriteStreamAh, ok. And for
gist-backupI filed an issue.
Btw, that's not a full modules list.Btw, that's not a full modules list.
Yes I understand that, but anyway a module that is using a callback to check for error is wrong. It should listen for the
errorevent, like with any stream.But the PR also added this part:
else if (typeof options === 'string') options = { encoding: options };so reverting it would break code relying on this new functionality...
I suggest we could fix that instead.
A simple check on whether the second argument is a function might work.4 remaining items
-1 on revert.
If revert this, we got the fs.createReadStream error again. #1412
This does not break compatible. We should check the arguments properly.
If the argument is wrong, we should assert the illegal arguments.@yosuke-furukawa brings up a good point – will more code break if we revert back to the original behavior than if we leave the change in? I suppose it boils down to: are more people erroneously passing strings to
createReadStream, or are more people erroneously passing functions tocreateReadStream?I am leaning towards patching the
typeof optionscheck to also allowfunction, and to treat it as an options object. We might look into what folks expect passing a function should do, also, so we can determine whether it's worth supporting that!Please allow both rather than only reverting one (and breaking new functionality) or leaving it in (and breaking existing functionality). Since we know it'd break something, it'd be semver-major!
Ridiculous solution: if they pass a callback then create a
new Error('no passing a callback!')pass that to the callback and return early.@trevnorris That would still be a breaking change.
Maybe it would be better to just ignore everything except strings and objects as an options?
-1: ignore
-1: revert
+0.5: replace error to deprecation #1982We should know what is the expected behavior when user calls
fs.createWritableStream('example.txt', function(){}).And we write the specification, we should follow the spec. we should not support the illegal function call.
https://iojs.org/api/fs.html#fs_fs_createreadstream_path_optionsIf this is breaking change, we already broke fs.createReadStream here. #635 #1412
this PR is landed in 1.5.0, it is not 2.0.0.Just my EUR .02 but the broken modules are broken because they are buggy. I don't see any reason to revert the change or add workarounds, just PR the offenders as a courtesy and move on.
@bnoordhuis One module is already fixed, and @targos already filed a PR for the second one.
I don't know if there are more. Also, see #1998.Edit: mentioned the wrong person, fixed. Sorry.
Yeah, I'm not so sure I like either also.
Ok, as no one (including myself) seems to actually support the idea of handling this (wrong API usage by modules) on the io.js side, I am closing both #1982 and #1998 PRs and this issue.
This is a bug in the module that is using the API in an incorrect and unsupported way.
A pull request targeting
karma-html-reporteris here: dtabuenc/karma-html-reporter#27 (thanks, @targos),karma-html-reportershould merge it to solve its problem.If anyone of @nodejs/collaborators thinks that this should be reopened or that there needs to be more discussion on this matter, just leave a message here.
@ChALkeR @bnoordhuis @cjihrig
Thank you soooo much. I agreed bnoordhuis and cjihrig's idea.
karma-runner/karma#1454