Allow augmentation of re-exported module

I’ve sadly discovered that it not possible to augment a ES2015 module that is being re-exported. At least not without specifying the full path to the ES2015 that is then being re-exported.

This has significant implications, particularly for library authors and consumers.

An example would probably help clarify.

Suppose as an authored of a library I want to expose a simple surface area from which consumers should import from. I do this by creating an index.ts file that re-exports modules from nested sub-folders like so:

// index.ts
export { AClass } from './path/to/class-a';
export { BClass } from './path/to/class-b';
export { CClass } from './path/to/class-c';

Now a consumer can import like so:

import { AClass, BClass } from 'some-library'; 

The benefits of the above:

1. As library author I am free to reorganise the modules into sub-folders as the library code base grows without breaking consumers
2. As library consumer I don’t need to have intimate knowledge of how the library organises it’s file on disk - instead I have one path to import modules and this is the name of the npm package itself.

Once augmentation enters the picture all of the above benefits are now gone.

This is really bad for everyone.

What can be done about the situation?

Thanks Christian

[RyanCavanaugh]

The OP is slightly ambiguous so I’ll address both.

If the request is to allow the exporting library to create a new type that augments AClass, that’s a strong “no” due to our current architecture and potential user confusion.

If the request is that augmentors can augment the exported AClass type as if it were declared upfront in the exporting library, 100% yes, that “should” work (where “should” is defined as “it is effectively feature work to support each possible variant, but we are on board with someone contributing that work”). Effectively, augmenting any type or value through its aliases should be the same as augmenting the type or value at its original declaration site.

[speigg]

Ah, this is why it’s not working. I’m trying to do the same thing as @endel (augmenting a re-exported class from the package-scoped three module).

EDIT, this worked for me:

declare module 'three/three-core' {
    interface Object3D {/* augmentations */}
}