Daniel Nixon

There is more work to do: https://github.com/danielnixon/eslint-plugin-total-functions/issues/732

I have implemented https://github.com/danielnixon/eslint-plugin-total-functions/issues/708, so this is now blocked on https://github.com/RebeccaStevens/is-immutable-type/issues/42

I'm deprecating this rule so closing this issue.

Similarly, we likely want to enforce `t.exact` / `t.strict` to avoid issues related to unsafe decoding, smuggling extra props, etc.

If we widen the scope of this to fp-ts generally, another useful rule might be forbidding lib imports. Good: ```typescript import { flow } from 'fp-ts/function' ``` Bad: ```typescript import...

Oh look, that already exists https://github.com/buildo/eslint-plugin-fp-ts/blob/main/docs/rules/no-lib-imports.md

This issue is less critical now that we have `PrincipledArray`: https://github.com/agiledigital/readonly-types/issues/7#issuecomment-1416679052 https://github.com/agiledigital/readonly-types/blob/master/src/index.test.ts#L170-L278

Nice work @haolinj 🚀

I can recommend https://github.com/eslint-functional/eslint-plugin-functional/blob/main/docs/rules/immutable-data.md and even https://github.com/eslint-functional/eslint-plugin-functional/blob/main/docs/rules/no-expression-statements.md Either of those rules will flag `Object.assign(x, { a: 3 });` as problematic.

It's difficult for this rule to catch this issue due to the way `Object.assign` is typed: ``` assign(target: T, source: U): T & U ``` The parameter type declared by...