-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
child_process: do not ignore proto values of env #18210
child_process: do not ignore proto values of env #18210
Conversation
This reverts this behaviour introduced in a recent PR, and updates the test. Without this change, CitGM and other packages are broken. Refs: nodejs@85739b6
Should we not revert this entirely? |
We don't need to. Just the prototype portion is excluded. To be honest, IMO that portion of the change kind of snuck through because the documented part is only re: undefined values. |
CI: https://ci.nodejs.org/job/node-test-pull-request/12586/ (Does CitGM use the newly built |
@apapirovski I think it does because the previous citgm errors seemed to be caused by citgm itself, not the modules that it was testing. |
Note that some of the modules tested by CitGM will fail on master: nodejs/citgm#517 |
To be clear, my approval is not just +1 to landing this but also +1 to considering this the right behaviour. |
Why is this conceptually the right behavior? By far, the language conventions when reflecting on objects are for only including own enumerable properties - eg Object.keys/values/entries/assign and object spread. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a nit.
@@ -504,7 +504,7 @@ function normalizeSpawnArguments(file, args, options) { | |||
var env = options.env || process.env; | |||
var envPairs = []; | |||
|
|||
for (const key of Object.keys(env)) { | |||
for (var key in env) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add a comment that flag that states that copying the prototype values is intentional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a comment to the commit before landing.
I think it would be breakage without any reason, and it would not have landed if we were aware that it would break CITGM. Moreover, the change was introduced to fix #15087, which is definitely not about the prototype chain. @ljharb if you want to pursue this specific change, can you send a different PR so it can be discussed separately? |
Landed in 38ee25e |
This reverts this behaviour introduced in a recent PR, and updates the test. Without this change, CitGM and other packages are broken. PR-URL: #18210 Fixes: nodejs/citgm#536 Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
@mcollina totally understand that the change was unintentional and breaking, so of course it should be reverted ASAP. Philosophically tho, im not sure why it’s desired. Before i invest time in pursuing a change, I’d love to understand why anyone thinks iterating the prototype is a good idea. @addaleax, can you (or anyone else if they share the opinion) elaborate on why? |
@ljharb I’m not sure, but it does feel more natural to me – in my head, the child’s |
We should look into why CITGM (or the modules it uses) relies on the prototype properties passed as env though. |
It’d be trivial to change: https://github.com/nodejs/citgm/blob/master/lib/create-options.js. |
In general, I'd be fine with limiting it to own properties only in a semver-major. |
What's not trivial is that there's an absolute ton of user-land code that relies on this behaviour: https://github.com/search?q=object.create%28process.env%29&type=Code&utf8=%E2%9C%93 It appears to be a VERY common pattern. |
That’s indeed a strong argument that it’s not worth the change, even if i think that “own keys only” is the correct/better conceptual model. |
This reverts this behaviour introduced in a recent PR, and updates the test. Without this change, CitGM and other packages are broken. PR-URL: nodejs#18210 Fixes: nodejs/citgm#536 Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
This reverts part of the behaviour introduced in a recent PR, and updates the test. Without this change, CitGM and other packages are broken. I would like to have this fast-tracked (like, land within an hour or less) because as things are, CitGM is completely broken.
Also, I would like to propose, that going forward all changes that are labeled as semver-minor/major/patch MUST have a CitGM run to land. If any issues are found, collaborators & TSC should decide whether those are blocking or not. In either case, an effort should be made to fix the impacted modules before the PR lands — or at the very least in cases where those modules are integral to the Node.js core project.
Refs: 85739b6
Fixes: nodejs/citgm#536
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
child_process, test