Repository navigation
tsconfig.json "lib": "dom" should include "dom.iterable"(?) #60959
Description
Activity
It's not clear what you would do if you were targeting a browser that doesn't have iterable, though?
Fair, I don't think many people do that though. And there are other tools to check compatibility (e.g. ESLint's eslint-plugin-compat); is it really TypeScript's role? (note that I don't have a strong opinion on this)
It's not clear what you would do if you were targeting a browser that doesn't have iterable, though?
Interesting consideration! Thoughts:
- Being able to use
"es2024.full"seems useful. - Not sure if that’s feasible but removing features would help in this case:
"lib": ["DOM", "-DOM.Iterable"]
- The rules for what is and isn’t included in
DOMcould be mentioned inmicrosoft/TypeScript-DOM-lib-generator. I thought the following rule applied in this case (but reading it again now, it probably doesn’t): “A feature needs to be supported by two or more major browser engines to be included here”
- Being able to use
It's not clear what you would do if you were targeting a browser that doesn't have iterable, though?
Why is DOM-iterable singled out? Is there a browser that supports ES2024, DOM but does not define
NodeList[Symbol.iterator]? This property has been cross-browser for a while.Reacted by lionel-roweFor one thing, until 5.0 (well, 5.5) TS still supported ES3, which didn't have iterators, so if they were included in
DOM, ES3 users would be unable to use the DOM types.Perhaps I'm missing some detail (I don't have the historical context), but I do wonder if we could get away with always loading
DOM.IterablefromDOM.Reacted by Axel Rauschmayer and fregante(Hm, but I don't think we even had ES3 types, so maybe this was never true.)
Ah, duh, sorry; replace ES3 with ES5 above (and we still support ES5, so the problem has not passed).
There must be loads of stuff in
lib.dom.d.tsthat wasn't available in ES5, e.g.AbortController/AbortSignal,TextEncoder/TextDecoder,URLSearchParams,ReadableStream/WritableStream/TransformStream, etc. Why doesSymbol.iterableneed to be the exception?Having something like
domnextas an analogue toesnextwould be an alternative solution to this. It's just weird having to include a special extra library to enable common patterns like[...document.querySelectorAll(sel)]when the intention is "assume whatever's in the latest DOM spec is available to my code".Reacted by freganteRelated: #54500 under "DOM tweaks"
Reacted by Daniel M., Kyle P Davis and HaiderReacted by lionel-rowe, fregante and Kyle P Davis"lib": ["dom"] will now automatically include dom.iterable as well
That's great news! 🎉
Reacted by HaiderSure, but those are different issues
This will be fixed by #62111.
Reacted by Axel Rauschmayer, fregante, lionel-rowe and Kyle P Davis- assigned and unassigned
on Sep 26, 2025
🔎 Search Terms
lib, dom, dom.iterable
🕗 Version & Regression Information
⏯ Playground Link
No response
💻 Code
🙁 Actual behavior
"lib"is omitted fromtsconfig.json."lib"is["es2024", "DOM"]"lib"is["es2024", "DOM", "DOM.iterable"]🙂 Expected behavior
Given how broadly supported DOM.iterable is, it should be part of DOM by now(?)
Interestingly, es2024.full looks like this but can’t be used as a value of
"lib":Additional information about the issue
No response