Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-exporting interface in namespace via export import is considered a "variable" #1353

Closed
MathBunny opened this issue Aug 23, 2020 · 4 comments
Labels
bug Functionality does not match expectation help wanted Contributions are especially encouraged

Comments

@MathBunny
Copy link
Contributor

Re-exporting interface in namespace via export import is considered a "variable"

Search terms

namespace, aliasing, import, export, re-exporting, interface

Expected Behavior

TypeDoc will produce a web-page consisting of two interfaces listed for the following code:

/**
 * Sample namespace exported that leverages aliasing. 
 */
export namespace admin.subnamespace{
  export import DemoInterface = demoInterfaceApi.DemoInterface; // DOES NOT WORK!
  export interface DemoClass extends demoClassApi.DemoClass {}
}

Actual Behavior

The following appears with variables as one of the sections:

Steps to reproduce the bug

Visit my repository: github.com/MathBunny/typedoc-namespace-bug-demo

  • All the source code is found in src
  • You can test and build via npm run build && npm run docs

This seems related to #1157 but I'm not sure if export import is fully supported yet or what the plans are for it; the issues aren't very clear on what is and what is not supported yet.

Environment

  • Typedoc version: 0.18.0
  • TypeScript version: 3.9.5
  • Node.js version: v12.18.1
  • OS: macOS High Sierra 10.13.3
@MathBunny MathBunny added the bug Functionality does not match expectation label Aug 23, 2020
@MathBunny
Copy link
Contributor Author

Adding to this, it also appears that enums aren't recognized correctly either, and they're labelled as variables.

export const AppPlatform: typeof appMetadataApi.AppPlatform = appMetadataApi.AppPlatform;

Here, appPlatform is an enum. The other option is to do:

export import AppPlatform = appMetadataApi.AppPlatform;

This doesn't seem to work either.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Aug 23, 2020

export import DemoInterface = demoInterfaceApi.DemoInterface;

TIL this is legal... Every other time I've only seen import = used to import something as a variable, as in the handbook - https://www.typescriptlang.org/docs/handbook/modules.html#export--and-import--require. Looks like a bug.

export const AppPlatform: typeof appMetadataApi.AppPlatform = appMetadataApi.AppPlatform;

This is a variable. TypeDoc's output is correct here. The export import variant should be parsed as a re-export, but isn't.

The chanes in #1157 were focused on the more standard export { a, b } used in modules, not namespaces.

Right now, TypeDoc has ImportEquals handled in the variable converter, it should really get its own converter which converts as re-exports.

@Gerrit0 Gerrit0 added the help wanted Contributions are especially encouraged label Aug 23, 2020
@MathBunny
Copy link
Contributor Author

That makes sense, thanks for following up. Okay, the focus of this issue should remain on the export import aspect.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Nov 28, 2020

This is fixed in the 0.20 beta running typedoc on the following:

export namespace NamespaceA {
    export interface InterfaceA { }
    //export type renamedInterfaceA =  InterfaceA; // WA to typedoc v0.15
}
export namespace NamespaceB {
    export interface InterfaceA { }
}
export namespace NamespaceC {
    export import renamedInterfaceA = NamespaceA.InterfaceA;
    export import InterfaceA = NamespaceB.InterfaceA;

    export class TestClass {
        testMethod1(options: renamedInterfaceA): any {}
        testMethod2(options: InterfaceA): any {};
    }
}

and then viewing NamespaceC shows the following, with the InterfaceA links going to the appropriate page:

image

@Gerrit0 Gerrit0 added this to To do in Version 0.20 via automation Nov 28, 2020
@Gerrit0 Gerrit0 moved this from To do to Done in Version 0.20 Nov 28, 2020
@Gerrit0 Gerrit0 closed this as completed Dec 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality does not match expectation help wanted Contributions are especially encouraged
Projects
No open projects
Development

No branches or pull requests

2 participants