Open danielnixon opened 3 years ago
You could probably fix t.type
to t.readonly(t.type(...))
too.
Similarly, we likely want to enforce t.exact
/ t.strict
to avoid issues related to unsafe decoding, smuggling extra props, etc.
t.type
This makes it somewhat easier to grok errors returned from deeply nested codecs.If we widen the scope of this to fp-ts generally, another useful rule might be forbidding lib imports.
Good:
import { flow } from 'fp-ts/function'
Bad:
import { flow } from 'fp-ts/lib/function'
Oh look, that already exists https://github.com/buildo/eslint-plugin-fp-ts/blob/main/docs/rules/no-lib-imports.md
t.type
unless it is nested within at.readonly
.t.array
, with fixer tot.readonlyArray
.