Improve type inference of Result<T, E>

[henrymercer]

Thanks @mbg for pointing out this drawback.

By defining Result<T, E> as a sum type Success<T> | Failure<E>, we can now infer that a Result is a failure if it is not a success. For example, if we have:

const a = new Success(2) as Result<number, string>;
if (a.isSuccess()) {
  logger.info(`Success with value ${a.value}`);
} else {
  logger.info(`Failure with error ${a.value}`);
}

we can now infer in the else branch that a.value must be a string.

[Copilot]

Pull request overview

This pull request refactors the Result<T, E> type from a single class with static factory methods to a discriminated union of Success<T> and Failure<E> classes. This improves TypeScript's type inference, allowing the compiler to correctly narrow types in conditional branches when checking isSuccess() or isFailure().

Changes:

• Replaced the single Result class with two separate classes (Success and Failure) that form a discriminated union
• Updated all call sites from Result.success() and Result.failure() to use new Success() and new Failure() constructors
• Updated tests to reflect the new API

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/util.ts	Refactored Result<T, E> from a single class to a sum type with Success<T> and Failure<E> classes implementing a common ResultLike interface
src/util.test.ts	Updated tests to use new Success() and new Failure() instead of static factory methods
src/init-action.ts	Updated imports and usages to construct Success and Failure instances directly
lib/init-action.js	Generated JavaScript code mirroring the TypeScript changes

Comments suppressed due to low confidence (1)

src/util.test.ts:567

• The test description still references "Result.success" but the implementation now uses "new Success()". Consider updating the test description to match the new API, for example: "Success creates a success result".

test("Result.success creates a success result", (t) => {

[mbg]

LGTM with one minor comment. Also, was there a particular advantage you found to the class-based approach over something like:

type Success<T> = { isSuccess: true, value: T };
type Failure<E> = { isSuccess: false, value: E };
type Result<T, E> = Success<T> | Failure<E>;