Use Static interfaces for ambient declarations in lib.d.ts


Sometimes users want to add static members to builtin classes like String / Object. Since these are defined as:
declare var Object: {
    new (value?: any): Object;
    (): any;
    (value: any): any;
    prototype: Object;
    getPrototypeOf(o: any): any;
    getOwnPropertyDescriptor(o: any, p: string): PropertyDescriptor;
And there is no way to extend ambients at the momemt: https://typescript.codeplex.com/workitem/917 an alternate solution would be to use an interface for static members of these classes e.g.:
//Pulled from lib.d.ts

interface Object {
    toString(): string;
    toLocaleString(): string;
    valueOf(): Object;
    hasOwnProperty(v: string): bool;
    isPrototypeOf(v: Object): bool;
    propertyIsEnumerable(v: string): bool;
    [s: string]: any;

interface ObjectStatic {
    new (value?: any): Object;
    (): any;
    (value: any): any;
    prototype: Object;

declare var Object: ObjectStatic; 
Ref : http://basarat.github.io/TypeScriptDeepDive/#/modellingstatics

This is similar to how the team wrote jquery.d.ts
Closed Jul 28, 2014 at 11:17 PM by jonturner
As part of our move to GitHub, we're closing our CodePlex suggestions and asking that people move them to the GitHub issue tracker for further discussion. Some feature requests may already be active on GitHub, so please make sure to look for an existing issue before filing a new one.

You can find our GitHub issue tracker here:


danquirk wrote May 31, 2013 at 3:31 AM

Thanks for the suggestion. We're aware of the desire for this sort of feature, we've discussed a few possible fixes for the future. Assigning to Jonathon who handles suggestions.

omlin wrote Jun 22, 2013 at 12:42 PM

Just wanted to add that this would be extremely useful if implemented anyhow.

E.g. in ASP.Net Ajax library there is a very useful method String.format, which is equivalent to the String.Format in C#. And currently there is no way of using this method with TS.

In SharePoint, ASP.Net Ajax library deployed by default everywhere, so no need to add any extra scripts to page, which makes impossibility of normally using String.format especially annoying :(

onyxring wrote Sep 8, 2013 at 2:05 AM

I agree very much. One of the cool things about Typescript has over Dart or Coffeescript is that it is touted as a superset of javascript. We currently can do this in javascript and there are several libraries that extend native types. Adding this change to the lib.d.ts file is a quick, non-invasive way of allowing Typescript to support already existing javascripts that leverage this feature of the javascript language.

airam wrote Nov 10, 2013 at 11:54 AM

Is there any way to add the format class method to the String object in an ambient declaration with the latest version of Typescript?

Bartvds wrote Jun 3, 2014 at 5:35 PM

Is this still on the map? Current state is pretty annoying.

For example just today I was working on code that uses Uint8ClampedArray, which is 100% API compatible with the regular Uint8Array, but I had to make a mess to make it working instead of just extending some interfaces.

For the project members: there is talk on DefinitelyTyped about this; many users encounter this problem and it is time to get it fixed. It has been dragging for months (year?)

If this cannot be solved soon in a official TypeScript release then we're going to schism the lib.d.ts into out own model, which would be a sad state because we'd be duplicating work and I think the community got better things to do then maintaining a second standard library (not to mention all the noise and confusion).

Bartvds wrote Jun 16, 2014 at 1:03 AM

This came up again today on DefinitelyTyped, again with the Date object, and few days ago also for String.

This needs to be fixed, it is a pain-point for the typing community.


Bartvds wrote Jun 18, 2014 at 7:45 PM

Another one where most of the Date object was replicated to be able to extend it: https://github.com/borisyankov/DefinitelyTyped/pull/2325/files#diff-6be96271143d1c9d774e7662de1ba0a0R12

tobiasz_cudnik wrote Jun 24, 2014 at 8:29 PM

Let me understand this clearly - this ticket is opened for a year and the only action needed to solve it is changing the way native ecma types are defined in lib.d.ts? What are the consequences of this change? Benefits are ability to extend both static and instance namespaces for native objects.

I've reach this place as I'm a sugar.js user, a lib which extends native types (the other notable one is rubyjs). I think you should support such kind of libraries.


zoidbergstein wrote Jul 12, 2014 at 9:19 AM

I faced yet another issue today, unrelated to monkey patching or other non-straightforward ways to use JS. Another reason to have flexible definitions for builtin types is that Javascript itself evolves and there are many competing implementations with different sets of experimental features.

Number.isNaN() seems to be in future ES6 Harmony, and there are at least 2 implementations in the wild: Mozilla and v8.


For my problem an ability to specify a different lib.d.ts using command line is enough

zoidbergstein wrote Jul 12, 2014 at 9:20 AM

See https://github.com/borisyankov/DefinitelyTyped/issues/2498 for a cross-reference. I didn't realize I couldn't edit comments once added.