-
-
Notifications
You must be signed in to change notification settings - Fork 207
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
Add Methods
type
#1066
Add Methods
type
#1066
Conversation
types/methods/list.d.ts
Outdated
import type {ExecaScriptCommon, ExecaScriptSync} from './script.js'; | ||
|
||
// The types seem to fail unless type aliases are used. | ||
// We do not know why. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot explain this.
The types fail unless type aliases are used. 🤔
Even if those types were directly exported, without using the Methods
object type.
On mobile right now, so I'll check tomorrow, but I'm a little skeptical that the new exports are subscript indexes of the Methods type, instead of just the types themselves. Also, the new exports aren't generic, so while the return type from currying might be assignable to them, I think we're loosing type information. |
The generic type is the Those method types should not be used where type inference is possible instead. When using type inference, the import {execa as execa_} from 'execa';
// `execa` type is inferred as `Execa<{preferLocal: true}>`
const execa = execa_({preferLocal: true}); So the main reason for those new types is when the Execa methods are passed as arguments to a function. If we added the import {execa as execa_, type Methods} from 'execa';
const runCommand = async (execaMethod: Methods['execa']<{preferLocal: true}>) => {
// ...
}
const execa = execa_({preferLocal: true});
await runCommand(execa); However, using import {execa as execa_, type Methods} from 'execa';
const runCommand = async (execaMethod: typeof execa) => {
// ...
}
const execa = execa_({preferLocal: true});
await runCommand(execa); So the only use case IMHO would be for functions that enforce that the caller uses a specific option. For instance, the example above would enforce that That being said, we are using
This is mostly a stylistic issue. The exported types would be the same, so this should not change your usage of those types. The reasoning behind grouping those types together under a
However, I am happy to update this PR to calling those |
Adding the |
5d8ce73
to
af4a534
Compare
55c326e
to
2aca70a
Compare
I found out two TypeScript bugs which were blocking this PR, but worked around it. The new exported types are: Ready for review @sindresorhus 👍 |
Fixes #1062.
This PR adds the
Methods['execa']
,Methods['execaNode']
andMethods['$']
types. Those are the types ofexeca
/execa(options)
, and so on.This is useful for TypeScript users passing bound/curried instances of
execa
around.Using
ReturnType<execa>
does not work due to the overloading of theexeca()
function (execa(options)
,execa(file, args, options)
, template string syntax). So,ReturnType<execa>
is the return type ofexeca(options)
but also ofexeca(file, args, options)
(i.e. aResultPromise
), which makes assigning it not work.