fix(typedoc): documentation & API completeness fixes

[SpacingBat3]

Acknowledgements

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• The changes are appropriately documented (if applicable).
• The changes have sufficient test coverage (if applicable).
• The test suite passes successfully on my local machine (if applicable).

Description

This PR focuses on TypeDoc fixes to document all types that should be public in API (and, by that definition, also exposes them if they weren't part of package entrypoint) and to avoid documenting types that are external (currently from listr2 package).

The aim for this PR is to restore (or even improve) documentation completeness that was in the past Electron Forge builds but since #3636 it was lacking important documentation references that are needed by users to exactly know how to configure Forge. It is still work-in-progress to achieve this goal, albeit many improvements were already completed and as a result, even current iteration of patch set is ready for discussion. At this point, I've checked Electron Forge documentation for most common types and I believe everything I wanted to resolve with this package was done as part of it already, marking this as.

Changelog / highlights

As there's a lot of changes, here are main highlights on what is being worked on. I've tried to split commits to make similar changes in different packages documented separately, as I mostly worked on this in smaller changes, for a bit more exhaustive documentation of changes.

Expose in API and document necessary types. (most of which are already part of API, being referenced by other types)

This exposes in API numerous types (common example of this is Maker*ConfigOptions set of types) that were not always exposed previously, but now they are consistently across makers.

There's a lot of them listed in commit logs, I gave up on listing it again there.

Convert some types to interfaces.

In TypeDoc, type has many disadvantages when documenting – it has no inheritance information, meaning it treats such types as their own thing, and for non-inline types this also means they might not be expanded to show properties and will also lose information which type was used to make the Forge ones. At runtime, due to types being also more flexible, interfaces are also believed to offer performance benefits, albeit this was not the factor I picked to use interface over type.

Make some existing types inline, if they are simple enough.

This was done for aliases, types that merge others, or some types that are usually used just once in API and are simple enough to be dropped from it without any lost information for the consumers.

This was also done only for currently non-exported types.

Link external types to upstream documentation.

Some packages like listr2 offer also their own documentation, which might be useful to point relations between Electron Forge and upstream types or show types that should not be documented by Electron Forge, yet Electron Forge packages use them without any modifications as part of their API.

Unify and improve TypeDoc configuration.

This mostly removes per-package typedoc.json from git and formatter ignores, and also drops typedoc.base.json file that wasn't used before, in favor of packageConfig I use for this patch-set. I also set the same properties as in typedoc.base.json even if typedoc.base.json should not have any effect (unless imported by typedoc.jsonc) from my understanding of how TypeDoc resolves configuration.

Update per-pakage Readme.md URLs to the TypeDoc docs to ones that seem to be valid. (!)

While I have noticed some differences between generated docs at https://js.electronforge.io and my locally-generated docs for some naming conventions of files, I have not yet checked what that difference comes from, plus I have no insights on whether Electron does normalize the file names in some way or not. This might require updates in the future, especially considering that move towards hosting docs at https://packages.electronjs.org is also planned. It at least now does not point towards broken and outdated documentation generated by old builds of TypeDoc.

Considered alternative approaches

• If exposure is not desired, but type should still be documented, it is possible to do so via plugin: typedoc-plugin-missing-exports This was not considered, as previous PRs (mainly #3636) suggest that this approach is discouraged.
• Albeit I personally think the documentation separation between projects is desired, it is also possible to document listr2 types as part of respective Forge packages which re-export them. This approach has IMHO no benefits, now that I document types by providing interfaces that inherit upon types that are used. Moreover, listr2 is no longer the only type I've included for this PR and for many it is fitting to link symbols to the upstream documentation.
• Additionally, as seen in To-Do list, I have hard time deciding on whether to provide higher-quality docs for some external types used by Forge as part of the API, or link to the (in most cases) manually-written docs, since TypeDoc might offer more accurate documentation with what is currently used in code that manually-written docs, plus it does a lot to help with searching, linking relations in types and having consistent formatting for documenting symbols, so I'm personally in favour of that approach, albeit this problem is still very much open to the discussion. Initially this was resolved by adhering to what was done in maker-wix but I find using interfaces and documenting code by them more appropriate and accurate approach of documenting the API.

[MarshallOfSound]

@claude review

[claude]

LGTM — this is a mechanical, low-risk PR consistent with the recent series of "expose *Config" commits already merged (see MakerRpm, PublisherStatic, PublisherBitbucket, PublisherGitHub, VitePlugin commits in history).

Extended reasoning...

Overview

This PR adds export type re-exports for internal config/option interfaces (e.g. MakerDebConfigOptions, MakerFlatpakConfigOptions, MakerRpmConfigOptions, VitePluginBuildConfig/VitePluginRendererConfig, several WebpackPluginEntryPoint* types, StaticArtifact, BitbucketAuth/BitbucketRepository, GitHubRepository) across 9 maker/plugin/publisher packages, plus a rename of MakerFlatpakOptionsConfig -> MakerFlatpakConfigOptions for naming consistency, and a typedoc.json tweak (removes an accidental duplicate packages/plugin/* entry point and adds excludeReferences, externalSymbolLinkMappings, and packageOptions.excludeExternals).

Security risks

None. No runtime logic changes at all — every diff hunk is either a type-only export/re-export or a docs-generation config file. Nothing here touches auth, crypto, network I/O, or file-system permissions.

Level of scrutiny

Low. This is purely additive type surface (public API types becoming importable) and a doc-tooling config fix. I verified the one rename (MakerFlatpakOptionsConfig -> MakerFlatpakConfigOptions) is applied consistently at both its declaration and usage site, with no other references to the old name remaining in the codebase. I also checked that re-exporting a type that was imported via import type (as in VitePlugin.ts) compiles cleanly under this repo's tsconfig, since the repo does not set verbatimModuleSyntax or rely on it erroring in that case — confirmed with a local tsc repro matching this repo's module/target settings. All newly re-exported type names were confirmed to exist in their respective Config.ts source files.

Other factors

This PR is one in an identical sequence of already-merged commits doing the exact same "expose *Config" pattern (visible in recent git log: rpm, github, bitbucket, static, vite maker/publisher packages), so it follows an established, already-reviewed pattern rather than introducing a new one. No CODEOWNERS-restricted or security-sensitive files are touched.