fix(plugin-dts): follow lib.dts.abortOnError when generating dts

[zthxxx]

Summary

• pass abortOnError through dts pipeline (tsc/tsgo) instead of always failing when type-check has error
• allow bundling to proceed when abortOnError is false despite diagnostics

Related Links

N/A

Checklist

• Tests updated (not required).
• Documentation updated (not required).

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

This PR fixes the DTS generation pipeline to properly honor the abortOnError configuration option. Previously, the TypeScript compilation would always abort when encountering type errors, regardless of the abortOnError setting. The changes ensure that when abortOnError is set to false, the build continues and bundling proceeds even when type-check errors are present.

Key changes:

• Thread abortOnError parameter through both tsc and tsgo compilation pipelines
• Conditionally throw errors based on abortOnError setting instead of always aborting
• Allow bundling to proceed when errors exist but abortOnError is false

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
packages/plugin-dts/src/tsc.ts	Added abortOnError to EmitDtsOptions type and modified error handling in handleDiagnosticsAndProcessFiles and solution builder path to conditionally throw based on this flag
packages/plugin-dts/src/tsgo.ts	Modified handleDiagnosticsAndProcessFiles to accept and use abortOnError parameter, passing it through from emitDtsTsgo function
packages/plugin-dts/src/dts.ts	Extracted abortOnError from options, passed it to emit functions, and updated tsgo bundling condition to allow bundling when errors exist but abortOnError is false

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Timeless0911]

When bundle: false with abortOnError: false, the error should still be throwed I think. abortOnError means not exit the process instead of not throwing error.

[zthxxx]

If we throw an error here, the outer dts generation flow will fail due to promise rejection, no matter whether bundle is true or false.

packages/plugin-dts/src/dts.ts:265

In other words, even when abortOnError is set to false, throwing here will still cause the whole external pipeline to stop and skip subsequent steps.

That’s why the error is handled without throwing in this case, allowing the process to continue as intended when abortOnError is disabled.

[Timeless0911]

Promise rejection is handled in main process.

rslib/packages/plugin-dts/src/index.ts

Lines 238 to 252 in 22abbc9

	for (const result of promisesResult) {
	if (result.status === 'error') {
	if (options.abortOnError) {
	const error = new Error(result.errorMessage);
	// do not log the stack trace, it is not helpful for users
	error.stack = '';
	throw error;
	}
	result.errorMessage && logger.error(result.errorMessage);
	logger.warn(
	'With `abortOnError` configuration currently disabled, type errors will not fail the build, but proper type declaration output cannot be guaranteed.',
	);
	}
	}
	});

When abortOnError is set to false, a warning will be printed and the process continue.

[Timeless0911]

We may optimize the behaviour when abortOnError set to false with bundle set to true. Now, if tsc/tsgo throws error, the logic in apiExtractor.ts will not be called.

When bundle set to false, throwing error is reasonable since no other operations will be performed.

In other words, abortOnError is used to prevent a process from exiting with a non-zero exit code. If you want to ignore type errors, you should set noCheck to disable type checking.