Declaration merging does not work using .d.ts files

[Emm]

TypeScript Version: 2.0.3

Code

npm install --save moment moment-timezone @types/moment @types/moment-timezone

import * as moment from "moment";
import "moment-timezone";

console.log(moment().format());
console.log(moment().tz("America/New_York").format());

Expected behavior:

The code compiles without incident.

Actual behavior:

test.ts(5,22): error TS2339: Property 'tz' does not exist on type 'Moment'.

Discussion:

The file node_modules/moment/moment.d.ts (the underlying type definitions used by moment) declares:

declare function moment(): moment.Moment;
// [snip]
declare namespace moment {
   // [snip]
    interface Moment {
        // [snip]
        format(): string;
        // [snip]
    }
   // [snip]
}

export = moment

While node_modules/@types/moment-timezone/index.d.ts contains:

import * as moment from 'moment';

export as namespace MomentTimezone;
export = moment;

declare module "moment" {
    interface Moment {
        tz(): string;
        tz(timezone: string): Moment;
        zoneAbbr() :Moment;
        zoneName() :Moment;
    }
    // [snip]
}

This seems consistent with what the handbook says about declaration merging.

[aluanhaddad]

moment now bundles its .d.ts as part of its package. @types/moment-timezone declares a dependency on moment (not @types/moment) with an incompatible semver range. This causes aware package managers to install an additional version of moment, which contains a moment.d.ts file. It this that is augmented. You can see this by use "goToDefinition" from within "@types/moment-timezone.d.t.s".

[JoshDSommer]

@aluanhaddad I'm currently having the same issue, I don't quite follow what you mean by "goToDefinition". @types/moment-timezone has a indext.d.ts file but no "goToDefinition" in it.

Edit, I guess could you elaborate on the correct way to do this?

[aluanhaddad]

What I mean is I think there's a problem because you have three versions of the moment typings after running the install command. What I mean by go to definition is that the location of the moment typings which are pulled in by your import * as moment from "moment" statement are different from the moments typing imported by the ambient module augmentation in moment-timezone.d.ts. First of all you shouldn't install the moments @types package because you're already installing moment which comes with its own typings. Secondly the moment typings package has a dependency on a different version of moment. Npm is installing that version in a subdirectory of @types/moment-timezone

[aluanhaddad]

Go to definition just refers to the common name of the command that navigates to the definition's location in most IDEs

[mhegazy]

// cc: @Andy-MS and @RyanCavanaugh

Thanks for reporting this issue. The problem is in moment-timezone the dependency is on moment@2.14.*, but your package depends on moment@2.15.0 this causes moment-timezone to have its own copy of moment and that is what it augments. this is obviously wrong. I have a fix out in DefinitelyTyped/DefinitelyTyped#11547.

For cases like this we should consider using peerDependecies instead of dependencies to ensure we do not get multiple copies.

[aluanhaddad]

@mhegazy what about the @types/moment package itself. If a package starts shipping its own declaration files, should the dedicated @types package be deprecated? The reason I ask is that even without the nested dependency @Emm would end up with multiple typings for moment by installing what he specified

npm install --save moment moment-timezone @types/moment @types/moment-timezone

[Emm]

@mhegazy, thanks for the diagnostic and prompt fix.

@aluanhaddad, the @types/moment package is a simple stub (it's nothing but a package.json and a README.md).

I think for now, it makes sense to say that packages shipping their own type definitions have this kind of stub package.

[mhegazy]

I would like to keep this open until DefinitelyTyped/DefinitelyTyped#11547 is merged and a new version of the package is published.