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

New rule: prefer-readonly-type-alias #255

Closed
wants to merge 3 commits into from
Closed

Conversation

RebeccaStevens
Copy link
Collaborator

Note: The rule might want a new name as it can also require aliases to be mutable.

By default, this rule requires that all type aliases are deeply readonly unless prefixed with Mutable.
I can however be configured to work the other way around and require that all type aliases are not deeply readonly unless prefixed with Readonly.

It's also possible to have a mixture of both these configure and to use other patterns to determine readonly vs mutable.

@RebeccaStevens
Copy link
Collaborator Author

Note: this rule is using typescript-eslint/typescript-eslint#3658

@RebeccaStevens RebeccaStevens added the Status: Blocked Progress on this issue is currently not possible. label Aug 7, 2021
@RebeccaStevens
Copy link
Collaborator Author

May want to wait for typescript-eslint/typescript-eslint#1758 to be fixed too.

If upstream takes too long to resolve the issues/PRs, we can copy-paste in the relevant code to our repo in the meantime.

@jonaskello
Copy link
Collaborator

What would be the use-case for checking that types are not readonly? I like the dualism vs checking for readonly but I think we might introduce functionality that is not needed to encourage functional paradigms. My concern is mainly that it might make it more difficult to refactor/change things in the future as we may need to continuously support this functionality whether it is used or not.

I think it would be enough to support emulation of a mutable attribute by naming convention. This would probably only be needed on the variable or field level. Compare how it works in reasonml.

@RebeccaStevens
Copy link
Collaborator Author

I did probably set this rule up to a little more that it needs to.

The intent was so that it could not only check for readonly types like prefer-readonly-type does, but would also be able to be configure such that it would be able to enforce type readonlyness in a consistent way as with how typescript internal types are named. That is to say, Array has ReadonlyArray, Set has ReadonlySet and Map has ReadonlyMap.

Thus the following use-case would be allowed (with some configuration, not by default):

type MyType = {
  foo: string;
  bar: string;
  readonly baz: string;
}

type ReadonlyMyType = {
  readonly foo: string;
  readonly bar: string;
  readonly baz: string;
}

The rule would be able to flag MyType if it was fully readonly; as if that was the case, it should be marked as a Readonly type.

@RebeccaStevens
Copy link
Collaborator Author

Closed in favor of #259

@RebeccaStevens RebeccaStevens deleted the readonly-type-alias branch August 28, 2021 04:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Blocked Progress on this issue is currently not possible.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants