Repository navigation
Inconsistent enumerability #20565
Description
Activity
- addedmetaIssues and PRs related to the general management of the project.Issues and PRs related to the general management of the project.
on May 6, 2018 timers are enumerable by spec and most if not all of the whatwg globals are unenumerable by spec
I know about timers and the whatwg ones. But that still leaves:
global process Buffer module requireSee #10405 for
global.moduleandrequireare only globals in the REPL. The other two can go either way, but I don’t see any strong argument to change the status quo.I think we could close this issue.
Reacted by snektimers are enumerable by spec
what spec?
AFAIK we don't have a spec.
Honestly I think there isn't a lot of value and there is a lot of breakage potential in making things enumerable/not-enumerable.
I think we should have a "new things are not enumerable" policy overall - and that anyone doing
Object.keys(process)are doing something extreme enough so thatObject.getOwnPropertyNameswon't be a big deal.what spec?
https://html.spec.whatwg.org/ - timers (and over 200 other window properties) are enumerable.
Chromium 66.0.3359.139 output for comparison:
> Object.keys(window).filter(x => !/^(on|webkit|screen|page|scroll)/.test(x)).sort() (75) [ "alert", "applicationCache", "atob", "blur", "btoa", "cancelAnimationFrame", "cancelIdleCallback", "captureEvents", "chrome", "clearInterval", "clearTimeout", "clientInformation", "close", "closed", "confirm", "createImageBitmap", "crypto", "customElements", "defaultStatus", "defaultstatus", "devicePixelRatio", "document", "external", "fetch", "find", "focus", "frameElement", "frames", "getComputedStyle", "getSelection", "history", "indexedDB", "innerHeight", "innerWidth", "isSecureContext", "length", "localStorage", "location", "locationbar", "matchMedia", "menubar", "moveBy", "moveTo", "name", "navigator", "open", "openDatabase", "opener", "origin", "outerHeight", "outerWidth", "parent", "performance", "personalbar", "postMessage", "print", "prompt", "releaseEvents", "requestAnimationFrame", "requestIdleCallback", "resizeBy", "resizeTo", "self", "sessionStorage", "setInterval", "setTimeout", "speechSynthesis", "status", "statusbar", "stop", "styleMedia", "toolbar", "top", "visualViewport", "window" ]
https://html.spec.whatwg.org/ - timers (and over 200 other window properties) are enumerable.
We don't follow that spec at all though, not with regards to limits, edge cases, return values and so on. If we want to consider following the DOM timer spec then we should probably work towards those goals.
I'm a maintainer in a fake timer library and there is quite a bit of code that deals with differences between Node and browsers :)
global.moduleandrequireare not enumerable anymore in the REPL. That reduces the list of globals that are questionable to:processandBuffer.It seems like perhaps this should be closed, as the remaining items are debatable? Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree (or open a PR). I'm just tidying up and not acting on a super-strong opinion or anything like that.
- added a commit that references this issue
on Jan 14, 2019
When looking at the
globalobject we have quite a few properties that are not enumerable and we have a couple that are.Using
Object.keys(global)currently results in:URLandconsoleare for example not enumerable. Should we maybe reconsider these and either set everything to being enumerable / not enumerable? Or should we just define that everything added from now will be not enumerable?I could also not find any issue that was directly about this before. Somewhat related: #8810