TypeScript: New APIs added to lib.d.ts may break client codes. Allow duplicated members in interfaces? Make lib.d.ts overridable?

I noticed that recently a lot of new APIs are added to lib.d.ts. Of cause this is a good thing, however my code breaks badly because of such update.

Previously I had added a lot of declarations in my code for HTML5 APIs that were missing in lib.d.ts . Now some of them are added to lib.d.ts, and I get quite a few “duplicated identifier” errors. For example, I had added this piece to play with fullscreen:

interface Document {
//...
  fullscreenEnabled: boolean;
  mozFullScreenEnabled: boolean;
  webkitFullscreenEnabled: boolean;
}

Now fullscreenEnabled and webkitFullscreenEnabled are available in lib.d.ts, and my code breaks, and I have to remove them. However, you are still missing mozFullScreenEnabled right? – well, waiting for the next break.

Web platforms are constantly evolving, it is not practical to expect lib.d.ts always up to date, so developers just have to write such compensating declarations from time to time. Can TS avoid such breaks? I have a few ideas:

Allow duplicated members in multiple interface declarations, as long as they are identical. In the fullscreen API example above, tsc should not fire errors. Optional compiling warnings are acceptable, to assist developers to remove redundant codes at convenient time.
Make lib.d.ts overridable. When tsc find conflictions between lib.d.ts and client codes, it should pickup declarations in client codes. This is because declarations lib.d.ts may contain bugs, developers should be allowed to workaround them. E.g. MutationObserver’s constructor was missing a parameter for a long time. Again, optional warnings are welcomed.

What do you think?

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 42 (13 by maintainers)

Most upvoted comments

We have the same issue, angular 2 just won’t compile to ES6 without duplicated declaration issues, if we use the --nolib option we get missing declarations issues. Angular 2 decided to don’t address this problem but rather delegate to typescript for the solution, it’s an extreme pain, what can we do other than manually editing source files which is not viable in the long term?

markdrake on Dec 29, 2015

I want to use some DOM4 APIs and installed dom4 typings (typings install -A dom4). What will happen when some DOM4 APIs are added to lib.d.ts in future? E.g.

interface ParentNode {
    children: HTMLCollection;
}

I also note that duplicate method in interface is not an error, but duplicate property is. E.g.

interface Element {    
    innerHTML: string; // error: duplicate identifer
    getAttribute(name?: string): string; // OK
    getAttribute: (name?: string) => string; // error: duplicate identifer
}

This is a strange divergence to me.

duanyao on Apr 12, 2016

Reference Type directives are designed to solve exactly this problem by providing a canonical lookup location for things which mess with the global scope.

Combined with the library decoupling work, I think we’re addressing all the scenarios here as best as is feasible. There will need to be some level of restructuring of code that found itself in this state, but fundamentally it is solving the problem where two people both want to declare something in the global scope.

RyanCavanaugh on Apr 11, 2016

I’m just getting started with TypeScript, and targeting ES6 because I want to use async/await. When I include the typings for whatwg-fetch, it references es6-promise.d.ts, and I get Duplicate identifier 'Promise' (x4).

Is there a way to fix this without manually updating the typings?

I tried to exclude es6-promise.d.ts using tsconfig, but it’s still included because it’s referenced by the whatwg-fetch typing (and from within tsd.d.ts).

Should the author of whatwg-fetch remove the reference, or should this be fixed by TypeScript itself? I imagine that this will continue to happen with other typings.

I don’t really know what I’m talking about, but in JS, if you define the same function twice, the last one will be invoked. Couldn’t TS type definitions behave the same way, i.e. the last loaded definition is used? … this probably makes no sense, but I’m just trying to find a solution.

glen-84 on Nov 18, 2015