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

@category appears under function type aliases (only) with typedoc 0.22.6 #1745

Closed
KillyMXI opened this issue Oct 19, 2021 · 7 comments
Closed
Labels
bug Functionality does not match expectation

Comments

@KillyMXI
Copy link

KillyMXI commented Oct 19, 2021

Search terms

Function type aliases, comment tags, category.

Expected Behavior

@category tag behavior is consistent across different entities. In particular, it's visibility in the documentation is governed by the same rule.

Prior to 0.22.6 it was properly used to categorize documentation entities and was not shown under any of them and that makes total sense for me.

Actual Behavior

Version 0.22.6 still uses it to categorize documentation entities, but also started to include it under function type aliases specifically (other type aliases and functions are unaffected by the change and no @category tag is shown for them).

Apparently this is caused by #1734 and 0d04c08

I see no sense to clutter the docs with this specific tag since it is used for grouping already.
If there is a good reason to show it then there should be clean rules and a way to override them.
Current behavior is very surprising.

Steps to reproduce the bug

Version 0.22.6 (0.22.5 is fine)

Code like this:

/**
 * Foo...
 *
 * @param data - Data...
 *
 * @category My category
 */
export type Foo<T,R> = (data: T) => R;

Typedoc options:

  "typedocOptions": {
    "categorizeByGroup": false,
    "categoryOrder": [
      "My category",
      "..."
    ],
    "customCss": "./assets/docs.css",
    "defaultCategory": "...",
    "disableSources": true,
    "entryPoints": [
      "src/foo.ts",
      "src/bar.ts"
    ],
    "includeVersion": true,
    "out": "docs",
    "sort": "alphabetical"
  },

Environment

  • Typedoc version: 0.22.6
  • TypeScript version: 4.4.4
  • Node.js version: 12.21.0
  • OS: Windows 10
@KillyMXI KillyMXI added the bug Functionality does not match expectation label Oct 19, 2021
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Oct 22, 2021

Ah, yep, this is a problem, easy fix at least

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Oct 22, 2021

Fixed in abc6263

@Gerrit0 Gerrit0 closed this as completed Oct 22, 2021
@KillyMXI
Copy link
Author

Hmm. I'm now trying it with 0.22.7 and the issue persists.

@Gerrit0 Gerrit0 reopened this Oct 31, 2021
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Oct 31, 2021

Yep... I'm seeing that too now, weird.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented May 30, 2022

This bug wins the prize for being the thing I've accidentally broken the most in the past 6 months, then run the tests, noticed, fixed, and broken literally the next time I touched the category code. Sheesh!

@LennardF1989
Copy link

LennardF1989 commented Aug 21, 2023

EDIT: I misread the title of this issue, do you want me to make a bug report out of this, or is it working as intended?

@Gerrit0 I think it's back again in 0.24.8 (and maybe before?).

Here is my test-case:

/** Type definition to make a clear distinction between successful and failed responses in the documentation */
export type ApiFailReason = string;

/** 
 * Type definition of function used to resolve a promise
 * 
 * @param value Test 1
 */
export type PromiseResolve = 
    /**
     * Lambda
     * 
     * @param value Test 2
     */
    (value: any) => void;

The description is not shown as part of the type (like would happen for the simple export type ApiFailReason = string;), but rather for the lambda itself. The param of value will show Test 1. I'm not even sure this is valid syntax... but VSCode accepts it and it seems logical?

image

image

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Aug 25, 2023

That would be a duplicate of #2372, but please open a new issue in general. I don't like pinging people for very old resolved issues

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

3 participants