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

Strange re-export behavior with @namespace #2444

Closed
jpolo opened this issue Nov 20, 2023 · 2 comments
Closed

Strange re-export behavior with @namespace #2444

jpolo opened this issue Nov 20, 2023 · 2 comments
Labels
bug Functionality does not match expectation

Comments

@jpolo
Copy link

jpolo commented Nov 20, 2023

Search terms

Expected Behavior

Expectation 1 :
When a namespace extends some type, I expect two possible behaviors : the documentation is copied OR the documentation forwards to the parent class / type / interface.

Expectation 2:
In my case, the namespace is a specialisation of the type (i.e. a generic type bound to a specified type parameter)
Simply re exporting would lose the type information, which can lead to an unclear generated doc.

Actual Behavior

The doc of a given namespace (repro "Number") re exports another namespace (repro : "Boolean") instead of the parent namespace (repro : "Comparable").

Also, it should not "lose" type parameters. (= Re export link might not be sufficient)

Steps to reproduce the bug

The doc

https://w5s.github.io/std/api/core/namespace/Number#==

The repo

https://github.com/w5s/std

Environment

  • Typedoc version: 0.25.3
  • TypeScript version: 5.x
  • Node.js version: 20.x
  • OS: macOS

Thanks again for your great project 👍

@jpolo jpolo added the bug Functionality does not match expectation label Nov 20, 2023
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Nov 25, 2023

Huh, that's weird, those symbols ought to be different, and not be caught by the reference creating code...

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Nov 25, 2023

Shoot... it is different, but the code I added in 0.24 to support resolving references across compiler instances works by checking declarations, and all instances share the declaration and therefore get treated as the same. I think the fix for this is to check symbol.flags & ts.SymbolFlags.Transient and do something special in that case... maybe...

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
Projects
None yet
Development

No branches or pull requests

2 participants