Sanctuary: @types/sancturay type error

Created on 18 Nov 2019  ·  6Comments  ·  Source: sanctuary-js/sanctuary

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
typescript

Most helpful comment

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

Notice the unknown types in 3.8.3:
image

And the type is correctly displayed for the 4.0.2 version:
image

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).

All 6 comments

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 [email protected], so TypeScript users could at least use these functions. What do you think of this approach, @toolsh?

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

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"

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. :)

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

Notice the unknown types in 3.8.3:
image

And the type is correctly displayed for the 4.0.2 version:
image

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).

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 🤷‍♂️

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Siilwyn picture Siilwyn  ·  5Comments

fnune picture fnune  ·  3Comments

davidchambers picture davidchambers  ·  8Comments

davidchambers picture davidchambers  ·  8Comments

andrei-cacio picture andrei-cacio  ·  8Comments