✨ expose Result<T> as public API

[rauhryan]

Motivation

Result<T>, Ok(), and Err() are already exported from the public module surface, but they are still marked @ignore in the API docs.

This PR makes those APIs explicitly public so follow-on work can reference Result<T> without relying on undocumented types.

Approach

• remove @ignore from Result<T>, Ok(), and Err()
• add public API documentation and examples for each
• leave unbox() internal

This is the base PR for the stacked allSettled() work.

[cowboyd]

I know I said that we should be perfectly aligned with the JavaScript, but now I'm having second thoughts. The reason is because "fulfilled" and "rejected" are very explicitly Promise nomenclature, and operations are not promises.

Also, we have a Result interface which we use everywhere.

thoughts?

[joshamaju]

I know I said that we should be perfectly aligned with the JavaScript, but now I'm having second thoughts. The reason is because "fulfilled" and "rejected" are very explicitly Promise nomenclature, and operations are not promises.

Also, we have a Result interface which we use everywhere.

thoughts?

If the goal is to reduce friction for newcomers, aligning with familiar JavaScript terminology like "fulfilled" and "rejected" makes sense. Even though operations aren’t Promises, these terms are widely understood and lower the learning curve.

The alternative would require introducing additional abstractions—such as Effection’s box utility or similar constructs from other libraries to achieve the same behavior.

[rauhryan]

Split this into stacked PRs as requested. This PR is now the base PR for exposing Result<T>, Ok(), and Err() as public API. The stacked allSettled() implementation lives here: rauhryan#1

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/effection@1149

commit: 98c30ba