refactor: improve Options types

[erickzhao]

This PR attempts to simplify how we handle the Options interface in Electron Packager.

There are two main problems to address:

1. External: the TargetArch and TargetPlatform types used in the Options interface are aliases to string. This is because we accept string values for custom mirrors of Electron, so any string const value passed in gets swallowed by the resulting type.

// the following types are functionally equivalent in TS!
type TargetArch1 = 'arch1' | 'arch2' | string;
type TargetArch2 = string;

2. Internal: the Options interface defines what options can be passed in as values, but also serves as the interface that we use to pass to the final packaging function. Along the way, many optional properties in Options are inferred and mutated. This approach makes our types inaccurate internally because we're using Options everywhere, even after inference occurs and some optional properties become required.

At a high level, we're addressing the two problems with some type refactors.

1. We no longer support arbitrary string values as platform and arch inputs in the types. This removes the superfluous ArchOption, PlatformOption, TargetArch, and TargetPlatform types. Users passing custom arch/platform values can still do so, but must cast their parameters using the OfficalArch and OfficialPlatform types.
2. Options now explicitly refers to the options that are passed in by the user. ProcessedOptions refers to the Options object after it is processed/inferred via metadata. ProcessedOptionsWithSinglePlatformArch refers to the ProcessedOptions object once it is guaranteed to have a single platform or arch value (rather than an array or comma-separated string). We use a fresh opts object every time the shape of our options changes rather than mutating the initial Options being passed in.

Note

There are some additional refactors we can make for future work to make this delineation clearer.
For example, the Packager class takes in ProcessedOptions as a parameter, which means opts.arch and opts.platform can be an array. However, these values are never used—Packager instance functions are only ever called with a separate ProcessedOptionsWithSinglePlatformArch arg.

[request-info]

Thanks for filing this issue/PR! It would be much appreciated if you could provide us with more information so we can effectively analyze the situation in context.

[MarshallOfSound]

Seems fine at a glance, will be hard to know how it plays until the PR integrating into forge shows up

[felixrieseberg]

Code looks overall good!

This is some real bike-shedding and feel free to just ignore me, but I don't love Official as a prefix, simply because it doesn't really mean much. We might as well call them Platform and Arch. Just a silly note though.

[erickzhao]

I don't love Official as a prefix, simply because it doesn't really mean much. We might as well call them Platform and Arch. Just a silly note though.

Yeah, the naming for the SupportedX vs. OfficialX types is confusing as well! I wonder if we should make the latter more concise and the former more explicit (e.g. Arch vs. ArchWithAll).

Either way, we're not tied to a naming scheme yet as long as we haven't flipped the release job's switch back on, so I'll ask for more Ecosystem WG opinions. :)

[continuous-auth]

🎉 This PR is included in version 19.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀