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

fix wrong enum type conversion #591

Merged
merged 1 commit into from
Sep 22, 2017
Merged

Conversation

shlomiassaf
Copy link
Contributor

@shlomiassaf shlomiassaf commented Sep 11, 2017

Running the enumerations basic example the enums are evaluated as they should but member, variables, signatures and every other reflection that contains a type will resolve the wrong type.

If we look at the enumerations example, this is a short version of the code:

export enum Size
{
    Small,

    Medium,

    Large
}

export module Size
{
    var defaultSize:Size = Size.Medium;
    
    function isSmall(value:Size):boolean {
        return value == Size.Small;
    }
}

Looking at the JSON output (slimmed down) for the isSmell member:

{
  "id": 367,
  "name": "isSmall",
  "kind": 64,
  "kindString": "Function",
  "flags": {
    "isExported": true
  },
  "signatures": [
    {
      "id": 368,
      "name": "isSmall",
      "kind": 4096,
      "kindString": "Call signature",
      "parameters": [
        {
          "id": 369,
          "name": "value",
          "kind": 32768,
          "kindString": "Parameter",
          "type": {
            "type": "union",
            "types": [
              {
                "type": "unknown",
                "name": "Size.Small"
              },
              {
                "type": "unknown",
                "name": "Size.Medium"
              },
              {
                "type": "unknown",
                "name": "Size.Large"
              }
            ]
          }
        }
      ],
      "type": {
        "type": "intrinsic",
        "name": "boolean"
      }
    }
  ]
}

The type for the parameter is wrong, it treats it as union type instead of the right type which is reference type to the enum reflection.

Also see visually from a rendered page:
image

After applying the fix:

{
  "id": 205,
  "name": "isSmall",
  "kind": 64,
  "kindString": "Function",
  "flags": {
    "isExported": true
  },
  "signatures": [
    {
      "id": 206,
      "name": "isSmall",
      "kind": 4096,
      "kindString": "Call signature",
      "parameters": [
        {
          "id": 207,
          "name": "value",
          "kind": 32768,
          "kindString": "Parameter",
          "type": {
            "type": "reference",
            "name": "Size",
            "id": 200
          }
        }
      ],
      "type": {
        "type": "intrinsic",
        "name": "boolean"
      }
    }
  ]
}

image

@blakeembrey blakeembrey merged commit e377524 into TypeStrong:master Sep 22, 2017
@bdbergeron
Copy link

I've updated to the latest release of typedoc, but my docs still generate with the inlined union of possible values instead of using the enum type. Any suggestions on how to fix this would be great.

/**
 * Available leaderboard types
 */
enum LeaderboardType {
    /** Current context */
    CURRENT_CONTEXT = "currentContext",
    /** All contexts */
    ALL_CONTEXTS = "allContexts",
    /** All friends, all-time */
    ALL_TIME = "allTime",
}

/**
 * Show leaderboards UI.
 *
 * @param type  Leaderboard type to show.
 */
function show(type: LeaderboardType): void;

screen shot 2017-10-12 at 1 21 20 pm

@shlomiassaf shlomiassaf deleted the fix-enums branch October 15, 2017 01:30
@aciccarello
Copy link
Collaborator

@bdbergeron I wonder if there is an issue with string enums. We should create a test for that.

@bdbergeron
Copy link

bdbergeron commented Nov 2, 2017

@aciccarello It looks like gulp-typedoc was specifying an older version of typedoc in the dependencies section of their package.json, and it was overriding the one in my package.json. I somehow must have missed them pushing an update about two weeks ago that fixed the version mismatch, but this issue is now resolved for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants