Re-export chain not working as expected

[saulecabrera]

Given a directory structure like the one below:

.
├── asconfig.json
├── assembly
│   ├── bar
│   ├── common.ts
│   ├── foo
│   ├── index.ts
│   ├── reexport.ts
│   └── tsconfig.json
├── index.js
├── package-lock.json
├── package.json
└── tests
    └── index.js

5 directories, 15 files

where:

foo and bar are directories that contain two files each:

//index.ts

export * from '<foo|bar>';

// Foo | Bar

export class <Foo | Bar> {
}

common.ts aggregates the imports from Foo and Bar:

import * as Foo from './foo';
import * as Bar from './bar';

export {Foo, Bar};

and reexport just reexports everything in common:

export * from './common';

When trying to import * from reexport, the following compilation error is raised:

ERROR TS2305: Module 'assembly/reexport' has no exported member 'Foo'.

 import {Foo, Bar} from './reexport';
         ~~~
 in assembly/index.ts(4,9)

If the named export in common.ts is replaced by a star export, things work:

export * from './bar';
export * from './foo'

Is this expected?

[dcodeIO]

This may well be a bug, hmm. Just one thing I notice is that

// common.ts
import * as Foo from './foo';
import * as Bar from './bar';

export {Foo, Bar};

is not equivalent to

// common.ts
export * from './bar';
export * from './foo'

in that the former introduces new namespaces, i.e. the class Foo would become Foo.Foo. May this be related?

[saulecabrera]

Yeah exactly, it's probably the namespacing that's causing the issue here as per my investigation. I provided both examples just to make it (hopefully) clearer.

[dcodeIO]

Just so I understand correctly, does the equivalent to the star exports work?

// common.ts
import { Foo } from './foo';
import { Bar } from './bar';

export {Foo, Bar};

[saulecabrera]

Oh my bad, I misinterpreted your previous comment.

The equivalent of the star exports doesn't work either. I get the same error. The namespacing might not be the issue after all.

[dcodeIO]

In this case, we are very likely looking at a perhaps not-so-trivial bug here, thanks :)

[bnbarak]

Hey, I will give this bug a try. When I reproduce, the "equivalent of the star exports" works for me.

/** assembly/foo/foo.ts **/
export const Foo = 123;

/** assembly/foo/index.ts **/
export * from './foo';

/** assembly/common.ts **/
import * as Foo from './foo';
export {Foo};

// export * from './foo'; // <-- WORKS

/** assembly/reexport **/ 
export * from './common';

/** assembly/index.ts **/
import {Foo} from './reexport';

Running node asc ../assembly results in the expected error, but the alternative works. So it might be a namespace issue.

ERROR TS2305: Module '../assembly/reexport' has no exported member 'Foo'.

 import {Foo} from './reexport';
         ~~~
 in ../assembly/index.ts(1,9)

FAILURE 1 compile error(s)

One more note, reexport.ts is successfully compiled.

Will do more digging!

[bnbarak]

@dcodeIO @saulecabrera Is there a way to execute the program without importing all the default helpers functions? There are about 40 default import that makes it a little hard to debug. I used conditioned breaking point, but wondering if there is clever way.

[dcodeIO]

I guess what you are seeing there are the imports across stdlib. These are necessary unfortunately to set the program up, since otherwise compilation would not work. One workaround could be to check whether the current file path of interest starts with ~lib or not. If it does start with it, it's from stdlib and is probably not of interest.

[dcodeIO]

Was able to reduce this a bit:

// index.ts
import { Foo } from './reexport';

// reexport.ts
export * from './common'; // changing to `export { Foo }` suppresses the problem

// common.ts
export { Foo } from "./foo";

// foo.ts
export class Foo {
}

So there seems to be something going on with the export * in reexport.ts.