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

Support for export import statements #159

Closed
fede-s opened this issue Dec 1, 2015 · 7 comments
Closed

Support for export import statements #159

fede-s opened this issue Dec 1, 2015 · 7 comments
Labels
enhancement Improved functionality

Comments

@fede-s
Copy link

fede-s commented Dec 1, 2015

I have a library that uses requirejs modules and then is published as a node module.
I like to structure my project so that there is only 1 class per file, and then I have 1 file that is the library entry point file that exports all the classes I want to make available.
See the following example

file lib-entry-point.ts

export import ClassA = require('./ClassA');
//Here I change the name of ClassB and would like that it's name on the docs is the name I choose here
export import IChangedTheName = require('./ClassB');
export import module1 = require('./module1');

/**
 * does something
 */
export function aFunction () {

}

file ClassA.ts

/**
 * Class named A
 */
class ClassA  {
}

export = ClassA;

file ClassB.ts

/**
 * Class named B
 */
class ClassB  {
    public name = "B";
}

export = ClassB;

file module1.ts

/**
 * module that exports Class C
 */
export import ClassC = require('./ClassC');

file ClassC.ts

`/**
 * Class named C
 */
class ClassC  {
}

export = ClassC;

To generate the documentation I chose "file" mode and added the 5 files to the src property. What I get is:

screen shot 2015-12-01 at 12 17 24

But, I would like to get this:

screen shot 2015-12-01 at 12 22 26

The problem is that if I want to get that result, ClassB name must be "IChangedTheName" and ClassC has to be contained within module1.ts

/**
 * module that exports Class C
 */
module module1 {
    /**
     * Class named C
     */
    export class ClassC  {
    }
}

export = module1;

So my question is, would it be possible to have typedoc interpreting the structure of the project from the export import statements and be able to set whatever name I want for my class at that point?

@sebastian-lenz sebastian-lenz added the enhancement Improved functionality label Dec 8, 2015
@sebastian-lenz
Copy link
Member

Hi, thank you for your long comment. I see your point here and it makes sense to me. I have to admit that TypeDoc currently has absolutely no special handling for import/export statements and I also see the need for something like that. I'm still quite unsure on how to implement something like this as there are various use cases of import/export statements. My first step would have been to add a basic export table to the documentation al least gives basic information about the exported members of a module.

@iRath96
Copy link

iRath96 commented Jun 26, 2016

I've had this issue in a library of mine recently and decided to fork typedoc to implement this feature.
My implementation is by no means complete (and not very elegant either) but it might be useful nonetheless :)

https://github.com/iRath96/typedoc

@TheNeuralBit
Copy link

Is there any interest in closing this out by syncing and merging either https://github.com/iRath96/typedoc or #646? We export imports extensively in Apache Arrow and it would be great to have better support for this.

See ARROW-951 for more on our particular issue

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 16, 2019

It would be great to merge in #646 (looks more complete than iRath96's implementation) - we currently have quite a backlog of PRs and issues to address that are simply waiting on time.

@TheNeuralBit
Copy link

Understood. Anything I can do to help move #646 along? I could look into syncing it up with master if you think that would help.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Feb 18, 2019

That would be helpful since it would make it easier to pull and check that everything is working correctly before merging. Thanks!

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Jan 12, 2020

Support for this has been merged with #1157

@Gerrit0 Gerrit0 closed this as completed Jan 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improved functionality
Projects
None yet
Development

No branches or pull requests

5 participants