@types/sancturay type error

[toolsh]

Hi All,

I'm using sanctuary 2.0.1 and @types/sanctuary 0.14.2. I get below error in typescript. Would anyone help polish @types/sanctuary to make it consistent with sanctuary? Thanks a lot.

related to: https://github.com/sanctuary-js/sanctuary/pull/620

import S = require("sanctuary");
{}

import which = require("which");
undefined

var adb = S.encase(which.sync)("adb");
undefined

S.type(adb);
{ namespace: Just ("sanctuary-either"),
name: 'Either',
version: 1 }

adb.value
[eval].ts:5:5 - error TS2339: Property 'value' does not exist on type 'Maybe'.
5 adb.value
~~~~~
undefined

[davidchambers]

Thank you for reporting this problem, @toolsh. Using Sanctuary in TypeScript projects is currently problematic. TypeScript's intentionally naive left-to-right type resolution algorithm interacts poorly with Sanctuary's “data-last” API, and hacks are required to simulate type classes.

Significant effort has been expended trying to produce reasonable type definitions for Sanctuary over the past two or three years, most recently in DefinitelyTyped/DefinitelyTyped#37879 and in vicrac/DefinitelyTyped. The formidableness of the task has led several efforts to be abandoned.

We could add any => any-style type definitions for functions added since sanctuary@0.14.1, so TypeScript users could at least use these functions. What do you think of this approach, @toolsh?

[coodoo]

Sounds good to me, at least it could make those trivia warnings go away!

[samuelhnrq]

Hey, friendly neighborhood issue necromancer here. Does typescript 4 help with this? If not, lets any away. Given typescript is mostly a compiler and a flat out missing function definitions could lead to compilation errors. Or shimming.

OFFTOPIC:

This issue is so incredible it's kind of funny, not sure if I understand the "typescript hacks" thing correctly but it seems that the type correctness of this lib is so dense that you guys had to build a custom runtime type-checker (which is a sin in the sacred small production bundle church) and not even the de-facto (not preaching it's quality just it's ubiquity) can keep up in type checking.

I think I'm starting to comprehend the joke "there is a programming language in my type system"

[davidchambers]

Does typescript 4 help with this?

I don't know.

@lfarroco has been improving the TypeScript type definitions, most recently in DefinitelyTyped/DefinitelyTyped#45895. If and when anyone submits a pull request (to Definitely Typed) to add even one missing type definition, I will approve it. :)

[lfarroco]

It seems that v4 indeed improves type inference for curried functions.

Notice the unknown types in 3.8.3:

And the type is correctly displayed for the 4.0.2 version:

That will allow removing lots of overloads in the current declarations (we may need to check if existing overloads need to be kept for backwards compatibility, though).

[samuelhnrq]

Wait what I don't get it, backwards compatible with what? Unsafe code that might be exploiting the unknown return types? Besides, just bump the version 🤷‍♂️