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

process: freeze process.features #28242

Closed
wants to merge 1 commit into from

Conversation

joyeecheung
Copy link
Member

Refs: #25343

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

@nodejs-github-bot
Copy link
Collaborator

Sadly, an error occurred when I tried to trigger a build. :(

@addaleax
Copy link
Member

Hm, any particular reason for doing so? It seems like this might get in the way of mocking for testing, and I don’t really see how one would modify this object accidentally (= not on purpose)

@jasnell
Copy link
Member

jasnell commented Jun 15, 2019

Yeah, I'm not sure there's a really good reason to do this

@joyeecheung
Copy link
Member Author

@addaleax See #25343 (comment)
@silverwind

Not that I feel very strongly about this PR in particular, but from my experience mocking Node.js to test anything is usually a bad idea - that means the test can be easily broken by upstream changes that do not affect the functionality that you are actually testing, which would've been impossible if the code is written in some other stricter language or more robust platform. Not just mocking the platform - even mocking your own code can lead to very fragile tests.

@devsnek
Copy link
Member

devsnek commented Jun 16, 2019

also consider that a library may polyfill functionality and wish to therefore modify process.features.

@silverwind
Copy link
Contributor

silverwind commented Jun 16, 2019

My point about freezing is that a malicious library/actor could modify values and break software relying on process.features that way. Thought I do agree that "polyfills" (I think we call them monkey patches outside browsers) may present a valid use case.

Mocking for tests is not a valid reason to not freeze imho. We could instead just introduce a internal flag that is set during test runs which would not freeze it instead.

@addaleax
Copy link
Member

Mocking for tests is not a valid reason to not freeze imho. We could instead just introduce a internal flag that is set during test runs which would not freeze it instead.

To clarify, when I talked about tests I was talking about other people’s tests, not ours.

But more generally, I dislike the idea of giving JS objects special behaviour unless there’s a very solid reason to do so; JS objects are writable by default, and each exception is going to break somebody’s expectations (aka principle of least surprise).

@BridgeAR
Copy link
Member

BridgeAR commented Jul 5, 2019

What should be done here?

@BridgeAR BridgeAR added the process Issues and PRs related to the process subsystem. label Jul 5, 2019
@joyeecheung
Copy link
Member Author

I agree that allowing polyfills to modify this is a valid use case, so I will close this.

@joyeecheung joyeecheung closed this Jul 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants