Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fs: loosen validation to allow objects with an own toString function #34993

Merged
merged 1 commit into from
Sep 15, 2020

Conversation

ljharb
Copy link
Member

@ljharb ljharb commented Aug 31, 2020

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

This is a loosening of #31030 (which is only in v14 atm). It allows an object that has an own toString function, which does not conflict with the OP of #31030 which is primarily concerned with accidental stringification.

This unbreaks uglify-js v2, which is the last version that retains IE 8 support, which a few of my packages need. I'm hoping this strikes the right balance to avoid footguns while allowing idiomatic JS behavior.

@ljharb ljharb added the fs Issues and PRs related to the fs subsystem / file system. label Aug 31, 2020
@ljharb ljharb requested a review from BridgeAR August 31, 2020 04:24
@ljharb ljharb force-pushed the ljharb/fs_allow_stringifiable_object branch from 2a420f6 to 1e941c0 Compare August 31, 2020 04:26
@ljharb ljharb force-pushed the ljharb/fs_allow_stringifiable_object branch from 1e941c0 to f31b352 Compare August 31, 2020 04:56
@ljharb ljharb requested a review from mscdex August 31, 2020 04:57
@BridgeAR
Copy link
Member

I personally would rather not support this.

@ljharb
Copy link
Member Author

ljharb commented Aug 31, 2020

@BridgeAR can you elaborate on why not? It's highly idiomatic in JS to throw on null/undefined but then to stringify arguments, and this PR isn't even as loose as that - the only additional cases it allows are objects with an own toString, iow, which were explicitly intended to be stringified.

@Trott
Copy link
Member

Trott commented Sep 2, 2020

@nodejs/fs

@Trott
Copy link
Member

Trott commented Sep 2, 2020

@ljharb I think if you run make lint-js-fix and update your branch, that will resolve the minor lint errors.

Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM % lint errors, but as far as I understand, you'd need @BridgeAR to unblock this? (unless #34993 (comment) is non-blocking)

@ljharb ljharb force-pushed the ljharb/fs_allow_stringifiable_object branch from f31b352 to bfab9d0 Compare September 2, 2020 19:58
@ljharb
Copy link
Member Author

ljharb commented Sep 2, 2020

Updated. I believe the updated policy is that things are only blocking with "request changes", but obv I'd want @BridgeAR to confirm that.

@ljharb
Copy link
Member Author

ljharb commented Sep 2, 2020

The CI failures look unrelated to this PR, is it something known?

@Trott
Copy link
Member

Trott commented Sep 9, 2020

@BridgeAR Can you elaborate on your opposition? Is your opinion that we shouldn't maintain code for IE8 compatibility? Or something else? (And is it -1 opposition or -0 opposition?)

@Trott Trott added the request-ci Add this label to start a Jenkins CI on a PR. label Sep 9, 2020
@Trott
Copy link
Member

Trott commented Sep 9, 2020

@nodejs/collaborators This could use additional informed reviews.

@bmeck
Copy link
Member

bmeck commented Sep 9, 2020

this change means that supplying a Buffer is no longer guaranteed to have a simple path if I understand this? @ljharb do you know if the fix needs to run on Buffer/TypedArrayss or just random objects? I'd prefer we not invoke a toString on the special cased types.

@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Sep 9, 2020
@nodejs-github-bot
Copy link
Collaborator

Copy link
Member

@bmeck bmeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pending feedback on specialized types calling toString

@ljharb
Copy link
Member Author

ljharb commented Sep 9, 2020

@bmeck the case i'm concerned about is just a plain object, i am quite happy to only do the stringification on "not Buffers or TAs", if that would change your -1 to a >= 0 :-p

@bmeck
Copy link
Member

bmeck commented Sep 9, 2020

I'd be +1 with that change and a blurb in the docs about this special toString case

@ljharb
Copy link
Member Author

ljharb commented Sep 9, 2020

@bmeck so, looking again at my diff - all this does is doesn't throw on an object with an own toString function, inside validateStringAfterArrayBufferView - iow, i believe this is only called for non-Buffers/non-TypedArrays in the first place?

@ljharb ljharb force-pushed the ljharb/fs_allow_stringifiable_object branch from bfab9d0 to 7a169e8 Compare September 9, 2020 19:56
@bmeck
Copy link
Member

bmeck commented Sep 9, 2020

@ljharb confirmed, just looks like docs don't state this special case

@ljharb
Copy link
Member Author

ljharb commented Sep 9, 2020

Currently I see type signatures in the docs like * buffer {Buffer|TypedArray|DataView}, which doesn't even mention string - should i add string? how would i denote { toString: () => string }?

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Copy link
Member

@benjamingr benjamingr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the ping, I am also mostly +1 on this.

Actual code looks fine to me - though I would prefer it if we explicitly documented what happens when an object with toString is passed (like bmeck asked).

I would also appreciate (doesn't have to be here in this PR) a test that explicitly tests the behavior of an object with toString on the prototype.

I also think we might want to explore relaxing this behavior in the future (to allow toString on the prototype but not Object.prototype.toString which would result in errors)

@BridgeAR note this is only for objects that explicitly opt-in by defining toString on the object itself at the moment.

@nodejs-github-bot
Copy link
Collaborator

PR-URL: nodejs#34993
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Derek Lewis <DerekNonGeneric@inf.is>
@Trott Trott force-pushed the ljharb/fs_allow_stringifiable_object branch from 21d5020 to 9cf9e4a Compare September 15, 2020 23:47
@Trott
Copy link
Member

Trott commented Sep 15, 2020

Landed in 9cf9e4a

@Trott Trott merged commit 9cf9e4a into nodejs:master Sep 15, 2020
@ljharb ljharb deleted the ljharb/fs_allow_stringifiable_object branch September 16, 2020 04:42
ruyadorno pushed a commit that referenced this pull request Sep 21, 2020
PR-URL: #34993
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Derek Lewis <DerekNonGeneric@inf.is>
@ruyadorno ruyadorno mentioned this pull request Sep 21, 2020
4 tasks
@ljharb
Copy link
Member Author

ljharb commented Sep 24, 2020

Confirmed that node v4.12 solves my issue. Thanks!

joesepi pushed a commit to joesepi/node that referenced this pull request Jan 8, 2021
PR-URL: nodejs#34993
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Derek Lewis <DerekNonGeneric@inf.is>
chipx86 added a commit to chipx86/less-plugin-autoprefix that referenced this pull request Jan 9, 2021
A Node.js 14.x added strict type checking when writing files to disk,
preventing methods with their own `.toString()` method from being
written to disk and generating a `ERR_INVALID_ARG_TYPE` error in the
process. This affected using this plugin in combination with
`--source-map`.

The behavioral change was introduced in
nodejs/node#31030 and recently fixed in
nodejs/node#34993. That fix was not
comprehensive, and did not resolve the issue for the plugin.

To avoid this issue for all versions of Node, we no longer assume there
will be an implicit call to `SourceMapGenerator.toString()`. Instead,
it's now explicitly called when setting the data to write for the source
map, fixing source map generation.

This was tested on the latest releases of Node 12 through 15.
aduh95 pushed a commit that referenced this pull request Apr 4, 2022
The FS docs wrongfully indicated support for passing object with an own 
`toString` function property to `FileHandle.prototype.appendFile`, 
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`, 
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and 
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object 
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
aduh95 pushed a commit to aduh95/node that referenced this pull request Apr 4, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: nodejs#34993
PR-URL: nodejs#41677
Refs: nodejs#41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
aduh95 pushed a commit to aduh95/node that referenced this pull request Apr 4, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: nodejs#34993
PR-URL: nodejs#41677
Refs: nodejs#41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
juanarbol pushed a commit to juanarbol/node that referenced this pull request Apr 5, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: nodejs#34993
PR-URL: nodejs#41677
Refs: nodejs#41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
juanarbol pushed a commit that referenced this pull request Apr 6, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
aduh95 pushed a commit to aduh95/node that referenced this pull request Apr 6, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: nodejs#34993
PR-URL: nodejs#41677
Refs: nodejs#41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
juanarbol pushed a commit that referenced this pull request Apr 7, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Backport-PR-URL: #42631
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
xtx1130 pushed a commit to xtx1130/node that referenced this pull request Apr 25, 2022
The FS docs wrongfully indicated support for passing object with an own 
`toString` function property to `FileHandle.prototype.appendFile`, 
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`, 
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and 
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object 
was passed to `FileHandle.prototype.write`.

Refs: nodejs#34993
PR-URL: nodejs#41677
Refs: nodejs#41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
juanarbol pushed a commit that referenced this pull request May 1, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Backport-PR-URL: #42603
juanarbol pushed a commit that referenced this pull request May 31, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
danielleadams pushed a commit that referenced this pull request Jun 27, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
targos pushed a commit that referenced this pull request Jul 12, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
targos pushed a commit that referenced this pull request Jul 31, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: #34993
PR-URL: #41677
Refs: #41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
guangwong pushed a commit to noslate-project/node that referenced this pull request Oct 10, 2022
The FS docs wrongfully indicated support for passing object with an own
`toString` function property to `FileHandle.prototype.appendFile`,
`FileHandle.prototype.writeFile`, `FileHandle.prototype.write`,
`fsPromises.writeFile`, and `fs.writeSync`. This commit fixes that, and
adds some test to ensure the actual behavior is aligned with the docs.
It also fixes a bug that makes the process crash if a non-buffer object
was passed to `FileHandle.prototype.write`.

Refs: nodejs/node#34993
PR-URL: nodejs/node#41677
Refs: nodejs/node#41666
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. fs Issues and PRs related to the fs subsystem / file system.
Projects
None yet
Development

Successfully merging this pull request may close these issues.