TypeScript: Can not declaration merging for default exported class

Is there a way for augmenting a module exported with export = though? I wasn’t able to get it working.

i.e

knex.d.ts

interface Knex {
  test1: string;
}

export = Knex;

file.ts

declare module 'knex' {
  interface Knex {
    test2: string;
  }
}

You can only augment “exported” declarations. Class Foo is exported as default, and not as Foo. so the name Foo does not exist outside the module.

It just happens that default is a reserved word, and can not used as an interface declaration name.

The TS compiler needs to allow export { Foo as default} in module augmentation.

It seems to be working with the following convoluted setup:

some-library-you-cant-modify/Foo.ts

// This is the original class. You can't augment it directly because it's a default export.
export default class Foo {
  existingProperty: number;
}

my-library/typings/Foo.ts

import Foo from 'some-library-you-cant-modify/Foo'

// just reexporting the same class, but this time it's not a default export
export { Foo };

my-library/typings/Foo.d.ts

import { Foo } from './Foo';

declare module './Foo' {
  interface Foo {
    myProperty: string; // class Foo is now augmented with this added property
  }
}

my-library/consumer.ts

// Notice I'm importing from the original library, it works fine anyway.
// This means you don't have to update any existing code.
import Foo from 'some-library-you-cant-modify/Foo';

let foo = new Foo();
foo.existingProperty = 42; // we obviously can still access original properties
foo.myProperty = ""; // the added property works fine too, no compilation error

You’ll have to add your Foo.d.ts file in my-library/tsconfig.json:

{
  "files": [
    "typings/Foo.d.ts"
  ]
}

I wanted to point out that I think export-assigned (export =) classes have the same problem as default-exported classes of not being augmentable. There have been two questions (1, 2) about this on Stack Overflow in the past week. Given the lack of action on this bug, I didn’t think it would be helpful to file a separate bug for export-assigned classes.

Any time you export a default, you’re effectively creating a new name - so if you want to rename something globally, you have to search/replace for it, and track all the imports that re-export it. But by sticking to named exports, various refactoring tools can follow that name all the way through the code base 👍

On Fri, Sep 29, 2017 at 12:57 PM Joe Lapp notifications@github.com wrote:

Thanks @nevir https://github.com/nevir. Is the issue with defaults and refactoring that a class is less likely to have a single name across the entire application? Is that also an argument for not exporting functions directly but instead making stateless functions static methods on exported classes?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Microsoft/TypeScript/issues/14080#issuecomment-333223811, or mute the thread https://github.com/notifications/unsubscribe-auth/AAChnR1J5GO4IAiJhnQGefZc5XcMO-WJks5snUu-gaJpZM4MBduT .

default is a keyword of JS. By the way, you can export a new variable temporarily.

node_modules -> knex.ts

interface Knex {
  test1: string;
}

export = Knex;

custom knex.ts

import $knex from "knex";

const knex = $knex as typeof $knex & {
  test2: string;
}

export default knex;

@m93a I don’t think your scenario has anything to do with this issue since you aren’t using a class. Your idea 3 works if I export the MarkdownItStatic interface in the first file. It isn’t exported by default since the module has a default export expression (see this post), and it has to be exported in order to be augmented.

I’ve stopped using default exports in most cases - partly due to this, and also to make refactoring less painful

On Thu, Sep 28, 2017, 10:49 Joe Lapp notifications@github.com wrote:

Ugh. Here’s a prevalent use case for nested interfaces:

export default class MyController { constructor(options?: Options) { //… } }

namespace MyController { export interface Options { //… } }

Except you can’t do it yet on default exports.

Are people using a different pattern? Just not using default exports?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/TypeScript/issues/14080#issuecomment-332912883, or mute the thread https://github.com/notifications/unsubscribe-auth/AAChnSJ6MAONZ-j5pwNsuxcaos8l6rNsks5sm9wpgaJpZM4MBduT .

Thanks @nevir. Is the issue with defaults and refactoring that a class is less likely to have a single name across the entire application? Is that also an argument for not exporting functions directly but instead making stateless functions static methods on exported classes?