fix: weaken internal group types to strengthen return/onCancel types

[43081j]

This changes a few things.

First of all, trying to infer T while defining T currently doesn't work unless there's a member without the results arg. This is a known limitation that may or may not be fixed in typescript one day.

Until that happens, if ever, this dumbs down the type of results to be a Record<PropertyKey, unknown>. This means within a function you lose strong typing, but the return type will now always be correct.

Secondly, T is actually the resulting already-awaited shape. This means we do not need Awaited<T[K]> since T[K] is already the awaited type.

For example:

typeActualType={foo: number;bar: number;};group<ActualType>({foo: ()=>Promise.resolve(303),bar: ()=>Promise.resolve(808)});

You can see the ActualType never needed Awaited<T[K]> on each type since it is already the final result.

Importantly this does weak types within the callbacks/functions. so we need to decide between these options:

1. leave things as is. sometimes but not often, results is correctly typed and the return type is too
2. merge this PR, results is weakly typed but everything else is always correctly typed

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3e7a7de

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in Stackblitz • @example/basic • @example/changesets

npm i https://pkg.pr.new/bombshell-dev/clack/@clack/core@245

npm i https://pkg.pr.new/bombshell-dev/clack/@clack/prompts@245

commit: 3e7a7de

[43081j]

some examples before this PR:

// Correct return type, correct `results` type in 2nd functiongroup({foo: ()=>{returnPromise.resolve(303);},bar: ({results})=>{results.foo;// works, its a number!returnPromise.resolve(808);}});// Incorrect return type of {}, incorrect `results` type in both functions of {}group({foo: ({results})=>{results.bar;// doesn't work, {} has no bar propertyreturnPromise.resolve(303);},bar: ({results})=>{results.foo;// doesn't work, {} has no foo propertyreturnPromise.resolve(808)}});

examples after this PR:

// Correct return type, weak `results` type in functionsgroup({foo: ()=>{returnPromise.resolve(303);},bar: ({results})=>{results.foo;// works, but its unknown!returnPromise.resolve(808);}});// Correct return type, weak `results` type in both functionsgroup({foo: ({results})=>{results.bar;// works but is unknown!returnPromise.resolve(303);},bar: ({results})=>{results.foo;// works but is unknown!returnPromise.resolve(808)}});

[MacFJA]

Another approach is using class: Typescript Playground

Usage screenshot

With this:

• each step only knows previous steps result
• the "on cancel" action has a partial of the steps' type,
• the resulting type is the complete type

---

But the DX changes, it's not just a simple function with 2 parameters, but a class instance with multiple functions calls

[43081j]

Yes that pretty much works just because of the method chaining. But I don't think we can change the dx so drastically and inconsistently with the other functions

So we're still left with "weak types inside, but correct everywhere" or "strong types everywhere, but incorrect in most situations"

[natemoo-re]

Hmm I'm still not sure where I fall on this... we are looking ahead to a stable v1, so I think it would be okay to introduce a new approach for grouping prompts and deprecate group() until removal in v2. I know we're on a v0, so it's technically okay to rip the band-aid off, but that doesn't sit well with me.

[43081j]

that makes sense to me

introduce a new interface we can more easily type too and just drop the old one in 2.x

we can have a think about the shape of that on discord

[MacFJA]

Related to #139 (for the chaining implementation)

[43081j]

closing since this is old and will probably be solved another way