c:/sources/dojo-typescript/dojo.store.d.ts(24,29): error TS2173: Generic type references must include all type arguments.

c:/sources/dojo-typescript/dojo.store.d.ts(26,28): error TS2173: Generic type references must include all type arguments.

I noticed you recently closed the request for 0.9.5 and so started my migration to 0.9.5 but ran into errors due to "on" now requiring a boolean callback:

on(type: string, listener: (ev: Event) => boolean): Dojo.RemovableHandle;

Just curious as to purpose of this change. I couldn't see a point to it after skimming http://livedocs.dojotoolkit.org/dojo/on.

I think all takes any array as input (it does not have to be an array of promises). I believe you are missing this definition and can probably replace the first definition with this one:

(promises: T[]): dojo.Promise<T[]>;

see http://dojotoolkit.org/reference-guide/1.9/dojo/promise/all.html#dojo-promise-all

It seems additional error checking has determined these declarations are ambiguous:

dojo.d.ts(1158,9): error TS2175: Overloads cannot differ only by return type.
dojo.d.ts(1432,9): error TS2175: Overloads cannot differ only by return type.
dojo.d.ts(1437,9): error TS2175: Overloads cannot differ only by return type.
dojo.d.ts(1440,9): error TS2175: Overloads cannot differ only by return type.

I haven't had been able to work around this but the error is valid for these declarations:
val(): string;
val(): string[];

UPDATE 1: eliminated undefined get/set property by removing the quotes around "get" and "set":

class Stateful extends Dojo.DeclaredClass
{
    get(name: string): any;
    set(name: string, value: any, raiseChangeEvent?: boolean): void;

Also extended the getObject interface with context parameter:

    getObject(path: string, create?: boolean, context?: Object): Object;

Store.get(id: number) is not the only options. I add get(id: string): T;

Add "typeof" operator to *.d.ts files.

See issue and comment at:
http://typescript.codeplex.com/workitem/2020

Not sure I got this completely correct but domStyle set returns a computed style and get returns a string/number in some cases.

interface DomStyle {
getComputedStyle(node: HTMLElement): StylesMap;

get(node: HTMLElement, style: string): any; // string or number
get(id: string, style: string): any; // string or number
get(id: string): StylesMap;
get(node: HTMLElement): StylesMap;

set < T > (id: string, style: string, value: T): T; // string or number
set < T > (node: HTMLElement, style: string, value: T): T;
set(id: string, values: StylesMap): StylesMap;
set(node: HTMLElement, values: StylesMap): StylesMap;

}

Are there any plans for integrating this project :https://github.com/DefinitelyTyped
this project setup a package manager, for easy the distribution and updates of the typed version of a javascript library.

the packet manager project is here : https://github.com/DefinitelyTyped/tsd
and some grunt integration are on the way as well as nuget support.

i think this could help a lot in creating new projects using Dojo / and our library.

any thoughts ?

I am trying to extend existing dijit/form/button and provides additional funtionalities.
Compilation is no problem. But when running the custom class on Html. It complains that Dijit is not defined.
I modified to export the _Widget and still got the same problem.

/// <reference path="dojo.d.ts" />
/// <reference path="dijit.d.ts" />


import dojo_declare = module("dojo/_base/declare");
import widget = module("dijit/_Widget");
import button = module("dijit/form/Button");  // I have added the Button module in d.ts


class dfButton extends Dijit.Form.Button { 
             _setDisabledAttr(value) 
            { 
                (<any>this).set('readonly', value);
                (<any>this)._set('disabled', value);
            }

            _getDisabledAttr()
            { 
                return (<any>this).get('readonly');
            }
}

var module = dojo_declare("Button", [ widget, button ], new dfButton());
export = module;

interface Number
{
format(value: number, options?: {

From number.js:

number.format = function(/Number/ value, /number.__FormatOptions?/ options){

if(isNaN(value) || Math.abs(value) == Infinity){ return null; } // null

Your definition seems right to me. I should be able to provide a callback with 1, 2 or 3 parameters. But I've found that I must explicitly declare each signature.

For example:
forEach(array: T[], callback: (item: T, index: number, array: T[]) => void , thisObject?: Object): void;
forEach(array: T[], callback: (item: T, index: number) => void, thisObject?: Object): void;
forEach(array: T[], callback: (item: T) => void, thisObject?: Object): void;

I discovered that Microsoft recommends against using modules to create namespacing in external modules. From the "Needless Namespacing" section in their module doc.

To reiterate why you shouldn't try to namespace your external module contents, the general idea of namespacing is to provide logical grouping of constructs and to prevent name collisions. Because the external module file itself is already a logical grouping, and its top-level name is defined by the code that imports it, it's unnecessary to use an additional module layer for exported objects.

Microsoft pointed this out when I submitted this issue with invalid AMD output when I tried to extend a class in an ambient external module.

The SitePen blog post on TypeScript also shows an example of this style for dojo/_base/array.

From docs:
Returns a blended object that is an array of the instantiated objects, but also can include a promise that is resolved with the instantiated objects. This is done for backwards compatibility. If the parser auto-requires modules, it will always behave in a promise fashion and parser.parse().then(function(instances){...}) should be used.

Not sure the solution but for my purposes this works:

parse(rootNode?: HTMLElement, options?: _ParseOptions): dojo.Promise<dijit._WidgetBase[]>;

I guess best practices would require when(parser.parse)? I looked at the code and it is always a promise and http://dojotoolkit.org/reference-guide/1.9/dojo/parser.html indicates the array is for backward compatibility.

I'm digging your work. When I get so I know a bit more I'll try to pitch in.

I had trouble with the baseUrl method when I tried to plug this into an IBM Worklight project (because it has a good screen designer). baseUrl doesn't play nicely with Worklight, and I eventually figured out it was unnecessary anyway. You can add a hard-coded relative path in a require statement.

Given MyFile.html and MyFile.ts in the same folder, you can simply add a script to the end of the file as:

<script>require(["./MyFile.js"]);</script>

In my example, I already have a require for Dojo that Worklight generates, so I just tack it on the end. You could also use a different folder, e.g. "./js/MyFile.js".

If you're interested I'll post a simple example.

I would like to not diverge so far from the AMD world just yet. Particularly, I'd like to write code like this:

require(["dojo/_base/array"], function (array: dojo._base.array) { ... });

Is there a way to make use of your "dojo/_base/array" module in this way?

import dojo_declare = require("dojo/_base/declare");
import widget = require("Dijit/_Widget");
import templatedMixin = require("Dijit/_TemplatedMixin");
var x = dojo_declare(widget, templatedMixin);
export = x;

I got an error : Unable to invoke type with no call signatures.

Any idea how to call dojo declare?

I believe unwatch is deprecated and remove is preferred. I could not confirm this in the docs but do recall reading about it. I found a reference at http://www.sitepen.com/blog/2013/08/19/dojo-faq-aspect-handle-cleanup/.

So, WatchHandle should extend RemovableHandle:

interface WatchHandle extends RemovableHandle { unwatch(): void; }

Would be nice if we could have types at the module level for these:

dojo.Evented
dojo.Stateful
dojo.Deferred
dojo.Promise
dojo.Animation

So we can require(["dojo/Deferred"], function (Deferred: Dojo.Deferred) {});

Tried and failed with this:

declare module Dojo {
interface Deferred {
(canceler?: (reason: any) => void ): dojo.Deferred;
}
}

interface Array {...} is not defined with a generic so I'm not sure how to interpret the QueryResults definition. I'm guessing it's supposed to be finding the global Array (lib.d.ts) but it's resolving to the Dojo.Array instead? I don't know how to force it to use lib.d.ts.

Generic type 'Dojo.Array' requires 0 type argument(s).

I'm getting a lot of constructor errors in 0.9.5 and I am having a hard time resolving them. I think these were uncaught in 0.9.1. Here's an example:

require(["dojo/_base/Color"], function (Color: Dojo.Color) { new Color([1,2,3]); });

This is an error because I'm calling a constructor on what is declared as a class instance. This error makes sense. But how do I fix this? The only solution I can come up with requires defining interfaces (see http://stackoverflow.com/questions/20952911/why-in-typescript-0-9-5-do-i-now-get-a-bunch-of-invalid-new-expression-error). Am I overlooking something? I think if you could add a few examples it might help.

Have a look at what Bryan is doing with interfaces instead of classes at https://github.com/bryanforbes/core/blob/master/interfaces.d.ts. What are your thoughts on introducing (for example) IColor?

I could not successfully declare that NodeList extends Array so I added the one property I needed: length: number;

In reality getChildren is implemented in _WidgetBase but I'm not sure why it would be called unless operating on a _Container. I think _Container is the proper owner with current dijit.d.ts.