Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@types/sancturay type error #653

Open
toolsh opened this issue Nov 18, 2019 · 6 comments
Open

@types/sancturay type error #653

toolsh opened this issue Nov 18, 2019 · 6 comments

Comments

@toolsh
Copy link

toolsh commented Nov 18, 2019

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: #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
Copy link
Member

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
Copy link

coodoo commented Nov 28, 2019

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

@samuelhnrq
Copy link

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
Copy link
Member

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
Copy link

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

@samuelhnrq
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants