retry method

[ryoppippi]

sometimes, i want to retry some processes.
like

R.try({
	retry: 3
...
})

something like that

[Karibash]

@ryoppippi
Thanks for the suggestion!

byethrow is designed with simplicity in mind, so I’m currently unsure whether retry functionality should be built directly into the core library.

One idea is to provide this kind of feature in a separate package—something like @praha/byethrow-std —and include retry support there instead. What do you think about that approach?

[gunzip]

+1 for keeping retries out of the core library. There are dedicated tools for this, such as TanStack Pacer.

Alternatively, we could provide code snippets rather than maintaining external plugins. AI can handle the 'plumbing' for users anyway.

[Karibash]

I’m leaning toward providing retry support in a separate package (e.g. @praha/byethrow-std) so it’s available when people want it, but it doesn’t add complexity to the core. Something along these lines:

import { ResultStd, RS } from '@praha/byethrow-std';

ResultStd.retry(...);
RS.retry(...);

Also, it might be interesting to offer an optional “combined exports” entrypoint so users can import everything from one place:

// result.ts
export * from '@praha/byethrow/exports';
export * from '@praha/byethrow-std/exports';

import * as R from './result';

R.pipe(
  R.retry(...),
);

This way, the core stays minimal, but users who want a batteries-included experience can opt into it. What do you think?

[gunzip]

I'm okay with this approach if you'd like to move forward with it. However, I’m slightly concerned that it might become a maintenance liability over time, potentially taking focus away from the core development. Personally, I’d prefer using a dedicated library like pacer for retries, but I do understand there's a user base that would value a built-in, 'batteries-included' experience.

[Karibash]

For now, my top priority is expanding the documentation and building the ESLint plugin, so I don’t want to commit to maintaining a byethrow-std package just for retry yet.

That said, if more “std” candidates come up (beyond retry) and it starts to look like a genuinely useful bundle, then creating @praha/byethrow-std becomes a lot more realistic.

[gunzip]

Fair point. I think it’s crucial to define byethrow target audience first.

People usually choose a lightweight lib like byethrow - over a comprehensive framework like Effect - specifically for its replaceability and lack of lock-in. They want a specialized tool for Result types, while delegating other logic (like retries) to different specialized libs.

If you move toward a 'batteries-included' bundle, you risk ending up in a middle ground: too heavy for minimalists, but not complete enough for those who want a full ecosystem. Keeping the focus narrow imho preserves the modularity that makes this project attractive over more heavyweight solutions.

[youyoumu]

+1 for keeping retries out of the core library. There are dedicated tools for this, such as TanStack Pacer.

Alternatively, we could provide code snippets rather than maintaining external plugins. AI can handle the 'plumbing' for users anyway.

es-toolkit also has retry