-
Notifications
You must be signed in to change notification settings - Fork 173
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
try/tryit is incompatible with certain function overloads #60
Comments
This is a valid point. I struggle with it on occasion as well. If you, or anyone, knows how to make the typings more robust I'm all ears. Your workaround is interesting! In cases where TS gives me trouble I just inline the function: const [err, fileNames] = await _.try(() => fs.readdir(path))() In other cases: const [err, workspace] = _.try(async () => {
const users = await api.users.list()
const projects = await api.projects.list()
return map(projects, users)
})() |
Ah, I think the way you work around it is great. As for a pull request, I'm currently quite new to TypeScript, so I think I'll only come back in the future to make some changes haha. I'll be closing this issue as I don't think there's a need to keep it open 👍 |
Actually, I'll leave it open for others to make changes to the types. Sorry about that! |
If any Typescript wizards stumble onto this and know how to curry a function in TS and return a new function with the same types -- including the overloads, please do share. |
hello there =) I believe, there must not be a way to handle this issue. Based on my very little knowledge, in runtime Node will choose which function must be called based on the way that a function is called. in "tryit" function, the input func is not called but its argument is copied which I think makes the node choose which signature is appropriate for that input func. based on my testing for overloaded functions, the last definition is the chosen one. similar scenario: So I think there is no solution for overloaded functions, really =). I will be happy to know your opinion about this. |
Hey @Arash1381-y 👋🏻 I thought (mostly assumed) the same. It's awesome to see a concrete test with another lib that shows some proof. It's a bit of a bummer it isn't possible but it is an easy workaround to embed the arrow function inside tryit. |
Ok, so I was looking into this and I think this has no straightforward solution. According to this issue the problem with inference when used with overloads seems to be a design limitation. So I don't think we can have a simple way which solves this without some kind of workaround. To address this issue with the
To demonstrate these three alternatives I will use the import { readdir } from 'fs/promises'; Lambda wrapping const try_readdir = tryit(() => readdir(path))
const res = await try_readdir(); // [Error, undefined] | [undefined, string[]] Lambda wrapping with params const try_readdir = tryit((path: string) => readdir(path))
const res = await try_readdir('./dir'); // [Error, undefined] | [undefined, string[]] Explicit overload const try_readdir = tryit<
(
path: PathLike,
options?:
| (ObjectEncodingOptions & {
withFileTypes?: false | undefined;
})
| BufferEncoding
| null
) => Promise<string[]>
>(readdir)
const res = await try_readdir('./dir'); // [Error, undefined] | [undefined, string[]] Hope this helps |
I'm going to close this as an unfortunate limitation with a known workaround. |
I have been trying to use
try
withfs.readdir
from Node'sfs/promises
module. The typical function signature you would use is simply:Unfortunately,
fs.readdir
has 3 other overloads:Using
try
withfs.readdir
results in the last overload being used, making the second function parameteroptions
required (meaning I can't omit it at all) and returningDirent[]
in the promise.A possible workaround would be to place
fs.readdir
into a temp function like so:However, I find that the workaround loses its elegance in utility libraries like radash or lodash.
The text was updated successfully, but these errors were encountered: