[v3] Fix JS interface `execute` promise resolve values

[Lms24]

Problem Statement

According to our JS interface type definitions, the execute promise, as well as all abstractions (e.g. releases.uploadSourceMaps) building on top of it always have to return a Promise<string>.
However, in reality, if you execute a command with live: true (the second execute param), we resolve with void/undefined, thereby violating our type definitions.

Solution Brainstorm

To avoid behaviour breaking changes, we can leave this as-is for now but we should fix it in v3 of the CLI. We have two options:

• always resolve with a string (I'd prefer this slightly)
• change type definitions to allow for Promise<string | undefined>

[linear]

CLI-138 [v3] Fix JS interface `execute` promise resolve values

[szokeasaurusrex]

@Lms24 what is your suggestion for fixing this? Should we just make the behavior defined by live === 'rejectOnError' the default behavior for live === true and perhaps also remove the 'rejectOnError' option?

sentry-cli/js/helper.js

Lines 339 to 350 in 51273ea

	if (live === 'rejectOnError') {
	if (exitCode === 0) {
	resolve('success (live mode)');
	}
	reject(new Error(`Command ${args.join(' ')} failed with exit code ${exitCode}`));
	}
	// According to the type definition, resolving with void is not allowed.
	// However, for backwards compatibility, we resolve void here to
	// avoid a behaviour-breaking change.
	// TODO (v3): Clean this up and always resolve a string (or change the type definition)
	// @ts-expect-error - see comment above
	resolve();

[Lms24]

Making rejectOnError the behaviour for true and removing this value sounds reasonable to me! We could always introduce something like 'ignoreRejection' if there's a use case we need for live mode without promise rejections. I skimmed over our bundler plugins and didn't find anything where this change would be problematic.

Behaviour for live: false should remain unchanged though.