fp-ts: Use `unknown` type instead of `{}` (TypeScript 3.0+)

I see, thanks for explaining. That’s a bit hacky though and respect to {} would be a regression.

Another option is module augmentation: 2.9 users which want to upgrade to fp-ts@1.8.0 could augment global

declare global {
  type unknown = {}
}

or even better

declare global {
  // how io-ts's `mixed` type is currently defined
  type unknown = { [key: string]: any } | object | number | string | boolean | symbol | undefined | null | void
}

@mmkal yes, I just published https://github.com/gcanti/unknown-ts which exports

• mixed = { [key: string]: any } | object | number | string | boolean | symbol | undefined | null | void for older typescript versions
• mixed = unknown for >=3.1

I’m going to add unknown-ts as a dependency and publish a patch release

@gcanti with the release of typesVersions this can now be a non-breaking change, can’t it?

Interesting PR (“Adds support for “typesVersions” redirects”) https://github.com/Microsoft/TypeScript/pull/26568

Another proposal:

stick to typescript@2.3 features

In order to avoid stagnation, how do you feel about supporting last 2 stable releases?

For example currently latest release is 3.0.1 so fp-ts should support 2.9.2 and 3.0.1. When 3.1.0 will be released, fp-ts will support 3.0.1 and 3.1.0.

Yes, perhaps a little, sensible, easy fixable breaking change, but still a breaking change.

So looks like there’s only one option

release a major version everytime a new feature is used

That’s not desiderable though, given that TypeScript doesn’t follow semver and its release pace. For example let’s say we merge this PR and release fp-ts@2.0.0 then, since mapped tuples are on their way (just found out) and they could be useful to improve compose and pipe, the risk is that we are going to release fp-ts@3.0.0 soon afterward.

So if we want to avoid releasing major versions too frequently (and I do), we should “freeze” fp-ts and stick to typescript@2.3 features (as far as I know).