Repository navigation
refactor defineProperty usage #28967
Description
I've noticed that there is a lot of strange usage of `defineProperty" through the code base with slightly inconsistent options/configurations.
I don't mind helping out with this but I would need some help understanding the rules/thoughts behind some of these.
Furthermore if any of them need special configuration we should probably add tests for those...
Activity
ronag commentedon Aug 5, 2019
#28934 (comment)
[-]refactor defineProperty[/-][+]refactor defineProperty usage[/+]bnoordhuis commentedon Aug 6, 2019
Happy to provide input but can you phrase it as closed questions? ^^
ronag commentedon Aug 6, 2019
Sorry, I don't understand?
bnoordhuis commentedon Aug 6, 2019
Can you point to examples and explain what's unclear? The way your OP is phrased makes it kind of hard now to know where to start.
ronag commentedon Aug 8, 2019
https://github.com/nodejs/node/search?q=defineProperty%28+-path%3Adeps+-path%3Atest&unscoped_q=defineProperty%28+-path%3Adeps+-path%3Atest
In particular the configuration of
enumerableandconfigurableis unclear.http seems to like to set
enumerable: trueandconfigurable: truewith no defined reasoning: https://github.com/nodejs/node/blob/master/lib/_http_outgoing.js#L552Likewise buffer seems to have some extra configuration that seems unclear: https://github.com/nodejs/node/blob/master/lib/buffer.js
bnoordhuis commentedon Aug 9, 2019
I think most of those can be explained by the words "backwards compatibility."
E.g.
buffer.parentused to be an enumerable data property, now it's a getter. It makes no sense to redefine it (it'd be unsafe), hence it's non-configurable.I don't know why
outgoing.headersSentis configurable but it's probably for compatibility. It's enumerable because it was enumerable when it was still a simple data property.