feat(@clack/prompts): add prompt workflow

[Mist3rBru]

Since Typescript has shown a limitation on infer group results, discussed in @chrissantamaria's comment on PR#102, and Issue #131. This functionality presents an alternative for users who favor the builder pattern when dealing with multiple prompts in sequence, serving as either a workaround or an additional choice, while avoid a breaking change.

This PR includes:

• Code
• Docs
• Changeset
• Example

I am open to discussions on comment's section!

Closes #131
Closes #109

[changeset-bot]

🦋 Changeset detected

Latest commit: 3702152

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@clack/prompts	Minor

Not sure what this means? Click here to learn what changesets are.

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

[cpreston321]

Initial thoughts:

@Mist3rBru Great Work 🙏🏼 ,

I actually kinda of like this.. This could be a great addition. I'm just not for sure on the namespace builder. It almost sounds to me like a workflow. What are your thoughts?

Additional thoughts

I also think, within the next couple of releases -- I want to focus on knocking out a few bugs reported, then exposing each individual core prompt interface types to make it agnostic vs duplicating types that are already exist in core. This way someone can easily build on top of core as an agnostic layer like what we do for @clack/prompts. Then we can add another layer for themes etc.

Thanks,
CP 🚀

[Mist3rBru]

I agree, sounds more like an workflow, it could also change the add method to step.
Example:

await p.workflow()
  .step('name', () => p.text())
  .run()

[cpreston321]

@Mist3rBru I like that.

My only questions here

1. Should we deprecate groups in favor on this ?
2. Since this is the same functionality as group a end user might ask Which one do I use ?

[Mist3rBru]

We can release it, and open a pinned issue like v1.0.0 Roadmap, so people can give their thoughts, and we decide based on it.

[Mist3rBru]

I think it is a better API, since it does not deal with inference errors, and is more extensible.

[cpreston321]

@Mist3rBru I made some improvements to examples please check this out: de9f5b6

[Mist3rBru]

@cpreston321 commit included.

This helps a lot to run the examples!