DefinitelyTyped has a Dojo solution which uses named modules and may work with legacy Dojo and explicit typing. But these declarations do not facilitate TypeScript import, since there are no anonymous modules. It seems to be a more exhaustive and consistent version of schungx/Dojo-TypeScript, but without the declared modules which make import work.

schungx/Dojo-TypeScript does not allow for 'extends' of an import Dijit but provides both named and anonymous declarations.

Brian Forbes provides a dijit.d.ts definition which is good at consuming dijits from TypeScript. His solution is available here. It works perfectly well with import, since it uses anonymous module declarations, but still does not allow for TypeScript inheritance (even the incompatible type).

The following code allows me to develop TypeScript wijits that extend ContentPane that actually work (despite the inheritance compatibility).

declare module "dijit/layout/ContentPane"
    class w extends dijit._Widget {
        addChild(w: dijit._WidgetBase, index?: number);
    export = w;

It extends the _Widget class defined in schungx/Dojo-TypeScript and tricks tsc into thinking the ContentPane is a TypeScript class.

This is what extends means (d is derived class, b is base class):

var __extends = this.__extends || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();

The derived class gets all base properties, including prototype. But I've been warned several times that this is unsafe.

My questions:

  • 4
    Did the folks who advised you that this approach was unsafe explain why they thought so? Commented Feb 24, 2016 at 17:18
  • The gist of the concern was keeping it compatible with future version of the framework and making sure the component would work in various scenarios. I got it working and so I used it.
    – Corey Alix
    Commented Feb 25, 2016 at 17:23
  • 2
    That's odd reasoning. It is always possible code might not work with future versions...
    – Kat
    Commented Aug 23, 2021 at 15:40
  • 2
    It's been chugging along for the past 6 years so it worked out pretty well for me. We are still on 1.11 using the ESRI JSAPI 3.x so there never really was a future version in our future.
    – Corey Alix
    Commented Aug 23, 2021 at 15:43


Browse other questions tagged or ask your own question.