Repository navigation
properties created using Symbols in process.env are not intercepted #9429
Description
- Version: v6.2.0
- Platform: x86_64
- Subsystem:
switching off the flag PropertyHandlerFlags::kOnlyInterceptStrings in node.cc
causes Type Error when intercepting via Symbols on process.env collection,
which is strongly typed for Strings (error in EnvSetter in node.cc).
to reproduce: switch off the flag and run /test/parralel/test-v8-interceptStrings-not-Symbols.js
Activity
addaleax commentedon Nov 2, 2016
I am not sure… what behaviour would you expect?
AnnaMag commentedon Nov 2, 2016
The vm module intercepts both Strings and Symbols, while the current version of the process.env supports only Strings. This is to ensure that the properties are treated in the same way, no matter how they were created.
The test I referred to throws:
TypeError: Cannot convert a Symbol value to a string
with the flag off.
addaleax commentedon Nov 2, 2016
You’re right. But what do you think should happen when somebody does
process.env[someSymbol] = 42? Do you think the property should get set to'42', or do you think it should throw, or do you think the current behaviour is fine but should be documented? I can see arguments for all of these perspectives. 😄cjihrig commentedon Nov 2, 2016
Also keep in mind that
process.envis already a bit of a special snowflake, so it doesn't need to behave like a typical object.AnnaMag commentedon Nov 3, 2016
Having a flag makes strings optional + Symbols are commonly used, so my thinking is that it 'should' read and set values. That said, my understanding of the design choices here is limited and curious to hear all the perspectives.
bnoordhuis commentedon Nov 3, 2016
process.envmaps directly to the C environment and that only supports strings. If symbols are to be supported, they have to be turned into strings, there is no way around that.The default stringification for symbols isn't very useful (
Symbol().toString() == 'Symbol()'). Perhaps throwing an exception is the best course of action. It protects users against passing a symbol as the key by accident.Setting a symbol as the value already throws an exception (the 'Cannot convert a Symbol value to a string' error mentioned above.) Throwing on symbol keys would make it symmetrical.
jasnell commentedon Nov 3, 2016
I'd definitely be in favor of having a more specific
TypeErrormessage when using aSymbolas the key or value inprocess.env.src: throw on process.env symbol usage
src: throw on process.env symbol usage