You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add types for window.performance.getEntriesByType #33866
I found this old issue (Jul 5, 2018) and saw that experimental API's are not included in lib.dom.d.ts. The following API's don't appear to have experimental warnings on them on the MDN docs. Hopefully this means these are no longer experimental and types can be added now?
Getting specific strongly typed information for the entries when accessed via this API.
Examples
// resources would be of type PerformanceResourceTiming[]constresources=window.navigation.getEntriesByType("resource");// resources would be of type PerformanceMeasure[]constmeasures=window.navigation.getEntriesByType("measure");// marks would be of type PerformanceMark[]constmarks=window.navigation.getEntriesByType("mark");// paints would still be of type PerformanceEntryListconstpaints=window.navigation.getEntriesByType("paint");
Checklist
My suggestion meets these guidelines (not sure about the first one):
This wouldn't be a breaking change in existing TypeScript/JavaScript code
This wouldn't change the runtime behavior of existing JavaScript code
This could be implemented without emitting different JS based on the types of the expressions
This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
I think it makes sense to type these function return types depending on the second argument, so that if I call e.g. performance.getEntriesByName("myMark", "mark"), I properly get a PerformanceMark.
I'd like to take this. The change belongs in TypeScript-DOM-lib-generator, so I've prepared it there using additionalSignatures in overridingTypes.jsonc, the same mechanism getContext("2d") uses:
on both Performance and PerformanceObserverEntryList; other strings keep returning PerformanceEntryList
These three entry types exist in every environment that exposes Performance, so the worker libs get the same overloads. npm test passes. Types like "navigation", "paint" and "largest-contentful-paint" only exist in the DOM lib, so I left them for a follow-up rather than make the worker libs reference missing types. Happy to add them if there's a preferred way to make overloads DOM-only.
I'll open the PR on TypeScript-DOM-lib-generator unless you'd prefer a different approach.
Activity
third774 commentedon Oct 8, 2019
Doh! Tried to open a PR for this, but looks like the work is over in https://github.com/Microsoft/TSJS-lib-generator. Should I move this issue to that repo?
TaylorPzreal commentedon Jul 30, 2020
Waiting the feature.
DerGernTod commentedon Feb 3, 2022
any updates on this?
HolgerJeromin commentedon Sep 8, 2022
This is fixed since a few versions. Probably 4.4 or even earlier.
microsoft/TypeScript-DOM-lib-generator#1094 (comment)
billyvg commentedon Sep 20, 2022
Holger Jeromin (@HolgerJeromin) That is a different issue that doesn't address the return type of
getEntriesByType(), see https://www.typescriptlang.org/play?ssl=14&ssc=1&pln=14&pc=61#code/PTAEAUFMCcDMHtoFsCGA7AxpAcigbgJYDmKALgfGgCoFIFpEDaAugFAaUDOpoa+xZCmgCiaUtAKROoALygA7vQAm8eQDoADjATJ0WNUUilR4yZwBCATyqWtACgDkfQiXKUHASgDcrViAjaiKiYkABKUvAArtBYNHQMLOxcPNAR0VjScopoKupacEF6kAZGJhJSVjb2AESpnFExkNXevv5QBbohALKQKJzRkIkcaNygSL39dbIKyqqagZ36hsZi5RbWtpB21eN9A80+fmDtOsFYXSjQANZDyWOXV5kzOXP5p0UlK6YVGzWo1wdWscFmdIOAUPRSHF6EQkiMeBoIWIntlcvMOqDPmUzJVNttEZCDkAHolgerJeromin commentedon Sep 21, 2022
Ok, missed that detail. Current state models spec:
https://w3c.github.io/performance-timeline/#extensions-to-the-performance-interface
But yes could be more clear by adding overridingTypes:
https://github.com/microsoft/TypeScript-DOM-lib-generator#when-the-type-exists-but-is-wrong
BTW, added type debug information to your playground link.
schickling commentedon Apr 9, 2023
Is someone aware of any available NPM package that provides the missing types as a workaround for now?
RyanCavanaugh commentedon Jul 25, 2025
Confirmed on 5.9, the requested specialization is still not there.
It'd be great if OP's code example were correct (it's
.performancenot.navigator) and clarified the current behaviorDerGernTod commentedon Jul 28, 2025
If this is going to be worked on, I'd like to highlight that this also applies to
performance.getEntriesByName- it supports a second argument specifying the type: https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByNameI think it makes sense to type these function return types depending on the second argument, so that if I call e.g.
performance.getEntriesByName("myMark", "mark"), I properly get aPerformanceMark.Ankith-B commentedon Oct 11, 2026
I'd like to take this. The change belongs in TypeScript-DOM-lib-generator, so I've prepared it there using
additionalSignaturesinoverridingTypes.jsonc, the same mechanismgetContext("2d")uses:getEntriesByType("mark" | "measure" | "resource")→PerformanceMark[]/PerformanceMeasure[]/PerformanceResourceTiming[]getEntriesByName(name, type)overloads (as Gernot Raudner (@DerGernTod) suggested)PerformanceandPerformanceObserverEntryList; other strings keep returningPerformanceEntryListThese three entry types exist in every environment that exposes
Performance, so the worker libs get the same overloads.npm testpasses. Types like"navigation","paint"and"largest-contentful-paint"only exist in the DOM lib, so I left them for a follow-up rather than make the worker libs reference missing types. Happy to add them if there's a preferred way to make overloads DOM-only.I'll open the PR on TypeScript-DOM-lib-generator unless you'd prefer a different approach.
Add typed overloads for Performance.getEntriesByType/getEntriesByName
Ankith-B commentedon Oct 11, 2026
Opened microsoft/TypeScript-DOM-lib-generator#2572.