Skip to content

Relax TS1336 (An index signature parameter type cannot be a type alias) #24437

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

Closed
4 tasks done
bodawei opened this issue May 27, 2018 · 2 comments
Closed
4 tasks done
Labels
Duplicate An existing issue was already created

Comments

@bodawei
Copy link

bodawei commented May 27, 2018

Search Terms

  • TS1336
  • Type alias

Suggestion

It would be nice to be able to use a type alias that merely resolves to a number or a string in an index signature.

Use Cases

I sometimes create a type alias to allow me to express, more clearly, the kind of data a property holds, even when the underlying type is a simple primitive (e.g. number).

In the example, below, I want to tag any property that should hold a StateId as : StateId, even though StateId is really just a number. This makes it easier to to visually recognize what data is expected in a structure.

However, I'm not allowed to use a type alias in an index signature, even when the type alias is of the appropriate type.

Clearly, y'all have anticipated this and have given a useful error message (complete with the necessary fix) so that it will work. But, ultimately, I think it would be nice to just allow simple type aliases in this situation.

Examples

type StateId = number;

type TransMap = {
   [id: StateId]: SomeOtherType,   /// <---  This is the problematic line
};

This results in TS1336: An index signature parameter type cannot be a type alias. Consider writing '[id: number]: SomeOtherType' instead.

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript / JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. new expression-level syntax)
@jcalz
Copy link
Contributor

jcalz commented May 28, 2018

Duplicate of #1778?

@bodawei
Copy link
Author

bodawei commented May 28, 2018

Looks like a duplicate to me. I'll close this one as that one was closed. I'm, obviously, in the same camp as Yona-Appletree in that thread. Seems strange to me that I can create this alias and use it in some places but not others. From my perspective, it seems inconsistent (why allow the type alias at all if its use here seems irrelevant or misleading), and should I indeed change this underlying type I'll have to wade through a bunch of indexed types and change them from number to string or vice versa.

@bodawei bodawei closed this as completed May 28, 2018
@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label May 29, 2018
@microsoft microsoft locked and limited conversation to collaborators Jul 31, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants