You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Deprecate legacy fs.read and fs.readSync arguments #4530
This doesn't match what node does elsewhere. While preparing this PR, I experienced the very real cost that supporting this old usage causes. It increases the surface area for bugs in node core, as well as user code.
Can we get stats on how much this is used?
Can we, at least as a start, start printing a deprecation warning for this usage?
What about the "utf-8" string-type option that you can pass to createReadStream(..) (and createWriteStream(..) for that matter)? Is that similarly "legacy" to consider deprecating?
FWIW, there was a tutorial video released just today which uses the bare "utf8" (not "utf-8") string value with createReadStream(..).
A question of clarification: is the option really utf-8 instead of utf8? I've never seen it written as utf-8, and indeed the nodejs docs list it as utf8 (e.g. here).
I copied the 'utf-8' usage from the node.js tests, and that's indeed supported. I agree it's not ideal, but it's nowhere near as bad an undocumented/deprecated-but-not-really polymorphic fs.read function. Unless the node.js core folks disagree, I think removing 'utf-8' argument support is a separate discussion, for another issue.
What exactly are you suggesting deprecating @feross? The additional argument entirely? Just the utf8 option?
Usually the best path on these kinds of questions is to force the issue and submit a PR and you'll soon find out if there's any concerns, kind of like what's happening over in #4217.
On utf8 specifically I agree with @nathan7's point on boundaries but that doesn't apply to all possible encodings and perhaps there are good use-cases out there for this.
@chrisdickinson or @ChALkeR are either of you able to do a search on this to give us something to work with?
A quick and dirty search for cases where fs.read or fs.readSync is called with a second argument starting with numeric symbols or being a varible named length, count, num or size:
Activity
edef1c commentedon Jan 4, 2016
Additionally, decoding UTF-8 for anything but an entire file makes little sense, unless you're aware of code point boundaries. Total footgun.
getify commentedon Jan 4, 2016
What about the
"utf-8"string-typeoptionthat you can pass tocreateReadStream(..)(andcreateWriteStream(..)for that matter)? Is that similarly "legacy" to consider deprecating?FWIW, there was a tutorial video released just today which uses the bare
"utf8"(not"utf-8") string value withcreateReadStream(..).saibotsivad commentedon Jan 4, 2016
A question of clarification: is the option really
utf-8instead ofutf8? I've never seen it written asutf-8, and indeed the nodejs docs list it asutf8(e.g. here).feross commentedon Jan 5, 2016
I copied the
'utf-8'usage from the node.js tests, and that's indeed supported. I agree it's not ideal, but it's nowhere near as bad an undocumented/deprecated-but-not-really polymorphicfs.readfunction. Unless the node.js core folks disagree, I think removing'utf-8'argument support is a separate discussion, for another issue.rvagg commentedon Jan 5, 2016
What exactly are you suggesting deprecating @feross? The additional argument entirely? Just the
utf8option?Usually the best path on these kinds of questions is to force the issue and submit a PR and you'll soon find out if there's any concerns, kind of like what's happening over in #4217.
On utf8 specifically I agree with @nathan7's point on boundaries but that doesn't apply to all possible encodings and perhaps there are good use-cases out there for this.
@chrisdickinson or @ChALkeR are either of you able to do a search on this to give us something to work with?
feross commentedon Jan 6, 2016
@rvagg This PR is exactly what I was suggesting: #4525
ChALkeR commentedon Jan 13, 2016
A quick and dirty search for cases where
fs.readorfs.readSyncis called with a second argument starting with numeric symbols or being a varible namedlength,count,numorsize:fs\.readSync\([^,\)]+,\s+([0-9]+|(length|count|num|size)[^a-zA-Z]):fs\.read\([^,\)]+,\s+([0-9]+|(length|count|num|size)[^a-zA-Z]):As usual, has false negatives and checks only the latest versions of packages to the date when the dataset was build (that was on 2015-09-21).
dominictarr commentedon Feb 10, 2016
@nathan7 i'd argue that it's safer to decode
utf8via the option, since internally it uses string_decoder, which you need to know about otherwise.jasnell commentedon Apr 3, 2016
Closing since #4525 landed.