Repository navigation
process.features: deprecate it or add more properties? #25343
Description
Stem from #25291 (comment)
What I liked about process.config.variables.v8_enable_inspector is that it's also a user accessible way to detect if the inspector is enabled. Instead of moving to an internal solution it would be rad to expose this in a more user-friendly way.
Right now, there is an undocumented process.features for that purpose, but it has not been well-maintained. It's possible to detect certain features known at build time via process.config.variables but that object is mutable in the user land so it's not exactly reliable (whereas process.features have been immutable). Also it's not really a good design to have users rely on internal variable names.
Should we deprecate it in favor of a better feature detection API, or start maintain it properly?
Related: #22585 but that is more about availability of specific APIs like recursive fs.mkdir, whereas process.features have been more about higher-level feature sets.
Activity
addaleax commentedon Jan 4, 2019
Mutability is good – I’d be in favour of making
process.featuresmutable, too – at the very least, that’s helpful for testing purposes, and accidental changes are incredibly unlikely.I’d be 👍 on documenting this feature, esp. since I’d assume we can’t really remove it.
[-]`process.features`: deprecate it or adding more properties?[/-][+]`process.features`: deprecate it or add more properties?[/+]joyeecheung commentedon Jan 4, 2019
@addaleax I've took another look, the current behavior and the behavior before #25239 have both been that
process.featuresitself is not writable/configurable while the properties on it are (i.e. the object is not frozen).addaleax commentedon Jan 4, 2019
@joyeecheung Okay, sorry for not double-checking myself – then I’m totally fine with documenting
process.featuresand otherwise leaving it as it is. :)process: expose process.features.inspector
process: expose process.features.inspector
silverwind commentedon Jun 14, 2019
This looks like a great way to ease feature detection. I think we should document and require a addition to it for every feature that can not easily be detected (like new options), ideally as part of the PR that adds the feature.
I do believe that it should be frozen thought to be reliable.
jasnell commentedon Jun 26, 2020
I believe we can close this issue.
process.featuresis not going anywhere any time soon.