Router should not export Type Interface

[naomiblack]

We currently get two docs exported for Type Interface: one for core, and one for router. This is confusing -- and I think unnecessary duplication? Can we make Router depend on the Type exported from core?

[btford]

The router does depend on Type from core, but because it exposes a class with member of type Type, it must also re-export Type or TypeScript is unhappy.

@mprobst @alexeagle any ideas?

[mprobst]

I think that is WAI in TypeScript, if you don't re-export, downstream clients cannot understand your type signatures. You could re-export or relax the field to be of type any.

is the field private by chance? Because if so, then it'd be a valid feature request for TS to support this use case (not being required to re-export private fields).

[btford]

The field needs to be public.

I think this is something the documentation system is going to have to
change to handle.

On Thu, Aug 13, 2015, 18:30 Martin Probst notifications@github.com wrote:

I think that is WAI in TypeScript, if you don't re-export, downstream
clients cannot understand your type signatures. You could re-export or
relax the field to be of type any.

is the field private by chance? Because if so, then it'd be a valid
feature request for TS to support this use case (not being required to
re-export private fields).

—
Reply to this email directly or view it on GitHub
#3632 (comment).

[alexeagle]

Does this result in an error for users who import both typings? @jeffbcross checked that it should work.
If it's just documented twice, how severe an issue is that?

[btford]

This should be innocuous for the user. I think type Type = Function, or type Type = new (...args) => any, or something like that.

We could extend dgeni to filter out certain duplicates. I suspect we'll encounter the same problem with animations, http, etc. It might be reasonable to solve the general issue of duplicate exports. Or we could hard code a work around for now.

I think this will only really happen with shared utils like the façades. Could we check if the given class originates from src/facade/* and just not export those definitions?

Or we could possibly relax the type there to any, but that makes me kind of sad, and also makes the documentation worse for that class.

[btford]

@naomiblack – I'm going to unassign myself since this is not actionable on my end.