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: validate the input data to be of expected types #31030

Closed

Conversation

BridgeAR
Copy link
Member

The input was not validated so far and that caused unwanted side
effects. E.g., undefined became the string 'undefined'. It was
expected to fail or to end up as empty string.
Now all input is validated to be either some type of array buffer
view or a string. That way it's always clear what the user intents.

Fixes: #31025

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

@BridgeAR BridgeAR added the semver-major PRs that contain breaking changes and should be released in the next major version. label Dec 19, 2019
@BridgeAR BridgeAR requested a review from Trott December 19, 2019 18:11
@nodejs-github-bot nodejs-github-bot added the fs Issues and PRs related to the fs subsystem / file system. label Dec 19, 2019
@nodejs-github-bot
Copy link
Collaborator

@BridgeAR
Copy link
Member Author

@BridgeAR
Copy link
Member Author

BridgeAR commented Dec 19, 2019

The only CITGM errors that came up here are tests that just need a file and not the content. I opened a PR to fix their tests: ember-cli/ember-cli#8975

@Trott
Copy link
Member

Trott commented Dec 19, 2019

Will docs need to be updated to mention that the functions can throw in these situations? (I imagine "yes" but I haven't looked to see what they say right now.)

@Trott Trott added the notable-change PRs with changes that should be highlighted in changelogs. label Dec 19, 2019
@BridgeAR
Copy link
Member Author

BridgeAR commented Dec 20, 2019

@Trott I can do that but I think we never documented that in fs. I just checked other functions that also throw sync and the ones I looked at also do not have any documentation about that.

Should we maybe just outline in a generic fs part that input validation is synchronous?

Or should I only add an entry to the changes part?

Update: I just added the changes entries.

@nodejs-github-bot

This comment has been minimized.

lib/fs.js Outdated Show resolved Hide resolved
@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot

This comment has been minimized.

@Trott
Copy link
Member

Trott commented Dec 20, 2019

@Trott I can do that but I think we never documented that in fs. I just checked other functions that also throw sync and the ones I looked at also do not have any documentation about that.

In that case, I guess it's OK to omit. Someone can always go through and add the information at a later date. (Aside: Might not be a bad thing to add an entry to everything that throws indicating what it might throw, but that would be a pretty big project. @nodejs/documentation)

@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot
Copy link
Collaborator

@BridgeAR
Copy link
Member Author

@nodejs/tsc PTAL. This needs one more LG to be ready.

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@juanarbol juanarbol mentioned this pull request Dec 26, 2019
2 tasks
@BridgeAR
Copy link
Member Author

@nodejs/tsc this needs another review. PTAL

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot

This comment has been minimized.

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 2, 2020
@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot

This comment has been minimized.

@Trott
Copy link
Member

Trott commented Jan 4, 2020

Awaiting ember-cli/ember-cli#8975.

@BridgeAR
Copy link
Member Author

BridgeAR commented Jan 7, 2020

@Trott do you want to wait until the test fix is released? It is merged but the next release is up in 6-12 weeks. I would rather land this before that.

@Trott
Copy link
Member

Trott commented Jan 11, 2020

@Trott do you want to wait until the test fix is released? It is merged but the next release is up in 6-12 weeks. I would rather land this before that.

There is a release coming the week of January 19. I know you're eager to get this in, but I think a 2-week delay should be tolerable. Since this PR is a semver-major change, it won't end up in a Node.js release until April. So, at least as I see it, there's no reason not to wait two weeks to land this.

An alternative is to land something in CITGM's lookup.json to grab the master branch of ember-cli rather than the last release, but I think waiting for the release is preferable.

@Trott
Copy link
Member

Trott commented Jan 12, 2020

@nodejs/tsc This has enough reviews to land, but could probably stand a little more attention/scrutiny/awareness.

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

BridgeAR and others added 2 commits January 13, 2020 09:02
The input was not validated so far and that caused unwanted side
effects. E.g., `undefined` became the string `'undefined'`. It was
expected to fail or to end up as empty string.
Now all input is validated to be either some type of array buffer
view or a string. That way it's always clear what the user intents.

Fixes: nodejs#31025
@BridgeAR BridgeAR force-pushed the 2019-12-19-stricter-fs-input-checks branch from 1b78dae to e8940d0 Compare January 13, 2020 08:04
@nodejs-github-bot
Copy link
Collaborator

@BridgeAR BridgeAR removed the pending label Jan 25, 2020
@BridgeAR
Copy link
Member Author

BridgeAR commented Feb 5, 2020

Landed in fb6df3b, afe3530 🎉

BridgeAR added a commit that referenced this pull request Feb 5, 2020
The input was not validated so far and that caused unwanted side
effects. E.g., `undefined` became the string `'undefined'`. It was
expected to fail or to end up as empty string.
Now all input is validated to be either some type of array buffer
view or a string. That way it's always clear what the user intents.

PR-URL: #31030
Fixes: #31025
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Yongsheng Zhang <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
@BridgeAR BridgeAR closed this Feb 5, 2020
BridgeAR pushed a commit that referenced this pull request Feb 5, 2020
PR-URL: #31030
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Yongsheng Zhang <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
ZYSzys added a commit that referenced this pull request Feb 13, 2020
PR-URL: #31731
Refs: #31030
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Denys Otrishko <[email protected]>
targos added a commit to targos/citgm that referenced this pull request May 1, 2020
- Use Node.js 14 in actions/setup-node

- Add Node.js 14.x to the test matrix

- Remove CI: true from the environment

The variable is already set by GitHub

- Fix bug in test fixture

Discovered with v14.x because of
nodejs/node#31030.
targos added a commit to nodejs/citgm that referenced this pull request May 2, 2020
- Use Node.js 14 in actions/setup-node

- Add Node.js 14.x to the test matrix

- Remove CI: true from the environment

The variable is already set by GitHub

- Fix bug in test fixture

Discovered with v14.x because of
nodejs/node#31030.
@ljharb
Copy link
Member

ljharb commented Aug 31, 2020

fwiw i believe this breaks uglify-js v2 (i can't upgrade to v3 because it lacks IE 8 support). The specific value being passed into fs.writeFileSync is an explicit object with a toString function.

Could this validation perhaps be loosened, to still stringify objects that have a toString function? That would still throw on the nullish cases referred to in the OP.

@ljharb
Copy link
Member

ljharb commented Aug 31, 2020

Went ahead and submitted #34993, on the off chance the loosening would be accepted.

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.
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. notable-change PRs with changes that should be highlighted in changelogs. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fs.writeFileSync(path) literaly writes "undefined" to the file
9 participants