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

[Member] links don't render #1528

Open
joeduffy opened this issue Aug 9, 2019 · 5 comments
Open

[Member] links don't render #1528

joeduffy opened this issue Aug 9, 2019 · 5 comments
Labels
area/docs Improvements or additions to documentation docs/languages kind/bug Some behavior is incorrect or out of spec

Comments

@joeduffy
Copy link
Member

joeduffy commented Aug 9, 2019

We seem to use [Type] and [Method(func)] annotations in some of our API documentation, presumably hoping that these will get rendered as hyperlinks. For example, see Output:

At ‘deployment time’, the correct way to work with the underlying value is to call [Output.apply(func)]. This allows the value to be accessed and manipulated, while still resulting in an [Output] that is keeping track of [Resource]s appropriately. At deployment time the underlying value may or may not exist (for example, if a preview is being performed). In this case, the ‘func’ callback will not be executed, and calling [.apply] will immediately return an [Output] that points to the [undefined] value. During a normal [update] though, the ‘func’ callbacks should always be executed.

I assume the [Output.apply(func)], [Resource], [.apply], and various [Output]s, are intended to be hyperlinked to the relevant members?

This pattern is prevalent in the Pulumi SDK itself in addition to addition to packages like AWSX (Crosswalk). I believe @CyrusNajmabadi has written most of them, so we should ask whether this is a convention that should be being respected, or maybe the API docs themselves are simply wrong and should use a different syntax.

@CyrusNajmabadi
Copy link
Contributor

Yeah, basically this was a way to just call things out as being 'code related'. Happy to actually switch everything to an appropriate hyperlinking form once someone can tell me what that form should be that is reasonable stable :)

@justinvp justinvp added this to the 0.27 milestone Sep 9, 2019
@justinvp
Copy link
Member

justinvp commented Sep 12, 2019

We should investigate whether using JSDoc {@link} would do what we want. (Need to see how this comes back from TypeDoc).

https://jsdoc.app/tags-inline-link.html

@justinvp justinvp modified the milestones: 0.27, 0.28 Sep 12, 2019
@CyrusNajmabadi
Copy link
Contributor

There's no rhyme or reason on [] usage. It's just a way to callout that something is code versus non-code. I'm happy to go and adopt any sort of pattern that actually works. If we can make some sort of hyperlinkable tag, that would be excellent. @justinvp can you check and see what works and report back? i can then update our libs accordingly. Thanks!

@justinvp
Copy link
Member

Yep, I'll take a look and report back.

@justinvp
Copy link
Member

justinvp commented Oct 6, 2020

Editor support for @see and {@link} in JSDoc comment tags is on the roadmap for TypeScript 4.1. microsoft/TypeScript#35524

@susanev susanev added the kind/bug Some behavior is incorrect or out of spec label Apr 2, 2022
@justinvp justinvp removed their assignment Nov 24, 2022
@susanev susanev added docs/languages area/docs Improvements or additions to documentation labels Apr 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docs Improvements or additions to documentation docs/languages kind/bug Some behavior is incorrect or out of spec
Projects
Status: 🧳 Backlog
Development

No branches or pull requests

4 participants