Repository navigation
tsconfig.json "lib": "dom" should include "dom.iterable"(?) #60959
Description
🔎 Search Terms
lib, dom, dom.iterable
🕗 Version & Regression Information
- An issue as of TypeScript 5.7.2
⏯ Playground Link
No response
💻 Code
// Does TypeScript have the types for DOM iteration?
for (const x of document.querySelectorAll('div')) {}🙁 Actual behavior
- No error if
"lib"is omitted fromtsconfig.json. - Error if
"lib"is["es2024", "DOM"] - No error if
"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":
/// <reference lib="es2024" />
/// <reference lib="dom" />
/// <reference lib="webworker.importscripts" />
/// <reference lib="scripthost" />
/// <reference lib="dom.iterable" />
/// <reference lib="dom.asynciterable" />Additional information about the issue
No response
Activity
RyanCavanaugh commentedon Jan 13, 2025
It's not clear what you would do if you were targeting a browser that doesn't have iterable, though?
tbroyer commentedon Jan 13, 2025
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)
Fwiw: https://caniuse.com/mdn-api_nodelist_--iterator
rauschma commentedon Jan 14, 2025
Interesting consideration! Thoughts:
"es2024.full"seems useful.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”fregante commentedon Feb 18, 2025
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.jakebailey commentedon Feb 18, 2025
For 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.jakebailey commentedon Feb 18, 2025
(Hm, but I don't think we even had ES3 types, so maybe this was never true.)
jakebailey commentedon Feb 18, 2025
Ah, duh, sorry; replace ES3 with ES5 above (and we still support ES5, so the problem has not passed).
lionel-rowe commentedon Jul 8, 2025
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".jakebailey commentedon Jul 8, 2025
Related: #54500 under "DOM tweaks"
lionel-rowe commentedon Jul 8, 2025
That's great news! 🎉
phaux commentedon Jul 9, 2025
Maybe this is a good opportunity to also split
WebWorker.d.tsintoWebWorker.d.tsandServiceWorker.d.ts?#11781 #14877
jakebailey commentedon Jul 9, 2025
Sure, but those are different issues
jakebailey commentedon Sep 26, 2025
This will be fixed by #62111.