Daniel Nixon

@willheslam I've thought of an issue with the _a isTypeAssignableTo b_ and _b isTypeAssignableTo a_ approach. `readonly` is ignored for the purposes of assignability checking, which kinda defeats our purposes...

This seems very related: https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/#improved-depth-checks

In fact it would probably make sense to implement this in a way that users can specify as an option a list of types and methods that should be ignored...

@willheslam I'd welcome contributions here if you're interested in taking a crack ;-)

> I have a few examples of seemingly false positive "readonly assigned to mutative array" scenarios I've fixed _one_ of those just now: https://github.com/danielnixon/eslint-plugin-total-functions/commit/95acfaea315ada82abf298e10fe2f7f4a0c4c2f0

This should be considered "safe" for example: ``` const arr = ["a"]; const foo = foo; ```

That example is no longer flagged as invalid (thanks to https://github.com/danielnixon/eslint-plugin-total-functions/commit/6d4c3e58459062c8641772026412e66c5bf9be3e) but we still want the TSX test case(s).

This also applies to the new no-unsafe-mutable-readonly-assignment for the same reasons. Need to consider how to avoid flagging object (and array) literals there too.

@ilyub good point. I'm happy to accept a PR for that change. Object and array literals currently trigger `no-unsafe-mutable-readonly-assignment` as well. Relaxing both rules to not flag object literals sounds...

You could probably fix `t.type` to `t.readonly(t.type(...))` too.