Merging namespaces inside modules

[OliverJAsh]

2@rc

Given:

// typings1.d.ts
declare module 'knex' {
    export interface Test {
        foo: string
    }
}

// typings2.d.ts
declare module 'knex' {
    export interface Test {
        bar: string
    }
}

import {Test} from 'knex';
let y: Test = {} as any;
y.foo
y.bar

This works fine. However, given:

// typings1.d.ts
declare module 'knex' {
    namespace Knex {
        const foo: string
        interface Transaction {
            foo: string
        }
    }

    export default Knex;
}

// typings2.d.ts
declare module 'knex' {
    namespace Knex {
        const bar: string
        interface Transaction {
            bar: string
        }
    }
}

import Knex from 'knex';
Knex.foo
Knex.bar // error
let y: Knex.Transaction = {};
y.foo
y.bar  // error

It appears my namespace Knex is not being merged, because I can only access identifiers from typings1.d.ts. Why is this?

[DanielRosenwasser]

I believe that Knex refers to two "local" entities within each declare module block, and don't see each other. Just to better understand the scenario, why are you splitting an ambient module declaration across different files?

[OliverJAsh]

@DanielRosenwasser

Thanks for the fast reply.

I am trying to augment existing third party typings to provide corrections whilst waiting for upstream changes.

Specifically this interface, which I have modelled in the above example.

[mhegazy]

this is rather subtle. in a .d.ts file all top level declarations in a module are implcitly exported, e.g. in typings2.d.ts you did not need to write export namespace Knex. This rule does not hold if you have one of export default .., export {..} or export * from .. only declarations with export are exported. so in typings1.d.ts there is not really an exported name space, all what is there is a default export. the reuslt is that your other declaration does not augment it.

change you file to be:

// typings1.d.ts
declare module 'knex' {
    export namespace Knex {
        const foo: string
        interface Transaction {
            foo: string
        }
    }

    export default Knex;
}

[OliverJAsh]

Thanks @mhegazy, that makes sense. Is there something we can do to make this more explicit to the user? Silent failures are the worst!

[timruffles]

Would it be sensible to get the concept of explicitly aiming to merge a declaration into the language?

[timruffles]

Perhaps a merged modifier for declarations, that causes an error if at the end of compilation no merging took place:

declare merged module 'knex' {
  /// ...
}

*Sorry for double post - mishit submit.

[mhegazy]

Would it be sensible to get the concept of explicitly aiming to merge a declaration into the language?

merging is a core concept of the language. do not think a modifier makes sense here.

[mhegazy]

Is there something we can do to make this more explicit to the user?

It is about scoping rely. Adding an export = or export default for instance changes the scope of the module and "pushes" the declarations in one level. not doing so would result in unexpected consequences, e.g.

declare module "foo" {
    class inner {  ... }
    var x: inner;
    export default x;
}

if every thing was exported, then your module have an inner and an x along with the default export. i do not think this would be what the user intended.

so really, the only issue, is that export is optional in ambient contexts. so if you always use export modifiers, you should be good.