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

Suggestion: Enforce declaring method return types #333

Open
xirzec opened this issue Mar 15, 2022 · 1 comment
Open

Suggestion: Enforce declaring method return types #333

xirzec opened this issue Mar 15, 2022 · 1 comment
Milestone

Comments

@xirzec
Copy link
Member

xirzec commented Mar 15, 2022

Applicable ESLint rules:

Basically, consider a decorator helper like:

export function getStatusCodes(program: Program, entity: Type) {
  return program.stateMap(statusCodeKey).get(entity);
}

The inferred type is any because that's what stateMap returns, but really we know for this specific case it's string[] | undefined (or string[] when you have done an isStatusCode() check first.)

This requires consumers to look into our actual implementation code to determine the data types returned from decorator state methods, which is a bit time consuming and annoying. It also means that breaks could easily occur as we're not enforcing a public contract but relying on casting from any.

Consider the alternative:

export function getStatusCodes(program: Program, entity: Type): string[] {
  return program.stateMap(statusCodeKey).get(entity) ?? [];
}

Now a consumer knows exactly what they're going to get and they never have to worry about the undefined case.

@timotheeguerin
Copy link
Member

I agree this has been annoying consuming the decorator helpers and I have been trying to update as I use them. I would be fine having the type enforced for exported functions.

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

No branches or pull requests

5 participants