Rebecca Stevens

I can think of two ways to go about this: **Option 1** Add an option to the `prefer-readonly-type` rule called something like `style` with options `keyword` (default) and `generic` (maybe...

@jonaskello Thought's on this proposal?

So it seems like the original rule was designed around the idea of "make everything immutable so we can guarantee that mutations aren't happening", while this new proposal is more...

@jonaskello I'm thinking that it might best to deprecate this rule in favor of [@typescript-eslint/prefer-readonly-parameter-types](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/prefer-readonly-parameter-types.md). The core reason for this rule is to do what that rule is doing. The...

I'm thinking that we might want to add a new rule that deals with ensuring type aliases are readonly/mutable based on some condition. Then that rule in conjunction with `prefer-readonly-parameter-types`...

I made a start on this new rule. Right now the working name is [prefer-readonly-type-alias](https://github.com/jonaskello/eslint-plugin-functional/pull/255).

@jonaskello The new rule is mostly done now; just small tweaks to go and waiting on some upstreams. Essentially the rule is the same as `prefer-readonly-type` except it only works...

`ArrowFunctionExpression`, `FunctionDeclaration`, `FunctionExpression` are essentially checked by `@typescript-eslint/prefer-readonly-parameter-types` (just not the return type). So the main difference will be that variable declarations will not be checked (~`const foo: Array =...

We can also keep both rules around while we gather feedback from users.

My intention behind switching to the new rule and `prefer-readonly-parameter-types` was essentially that it makes work with 3rd-party libraries that aren't functional or provide readonly versions of their types vastly...