[DIT-10128] Better error messaging for config errors

[marla-hoggard]

Overview

Creates a new custom error class DittoError that allows use to pass specific error data from the call site to the error handler. This is similar to ApiError in the main app, but with stronger typing since we're starting from scratch.

Updates the error messages we surface to the user when we encounter a failure in the config file.

1. If we fail to read the yaml file (not valid format at all), the error message will tell them to make sure it's valid yaml
2. If it's valid yaml but doesn't match our schema, the error message will attempt to tell them which fields are extra or have invalid typing
3. Sends the zod issues in to sentry as extra -- this seemed to be the best place to put unconstrained metadata, but I'm not sure how to test this.

Context

https://linear.app/dittowords/issue/DIT-10128/improve-the-error-messaging-for-when-a-project-config-is-invalid

Test Plan

Testing successfully completed in via:

• Set your .env DEBUG to false so you only see what the user will see
• Edit your config.yml so it has a formatting/yaml error - you should see the right error message
• Add 1+ extra fields that shouldn't exist - the error should tell you which fields to remove
• Edit 1+ fields to give them invalid values for the expected type - the error should tell you which fields to look at
• Remove the outputs field, which is required - the error should tell you to check the outputs field
• All the errors above should use our default exit code of 2.
• Edit one of the new DittoError calls in projectConfig.ts to include { exitCode: 1 }, then trigger that error type - You should see Command failed with exit code 1 instead of the default which is 2.
• Do something that throws any other kind of error - you should see the generic error message

[jaerod95]

I think instead of Please remove or rename the following fields:
it might make sense to simply identify the incorrect fields:
The following fields have issues: ...field names
What do you think?

[marla-hoggard]

We could simplify to always just say that. But in this case, we know for certain the problem with those fields is that they exist at all (vs the other case where the fields are valid but their values are not). I was trying to be as helpful as possible without going too crazy deep into zod errors.

[jaerod95]

ah gotcha that makes sense. In that case we can keep this like this

[jaerod95]

I noticed it's only tracking the root level fields as invalid, i'm checking to see if there is a quick fix. Still testing but wanted to surface this

[jaerod95]

Suggested change

	const invalidKeys = Array.from(
	new Set(
	error.data.issues
	.map((issue) => ("keys" in issue ? issue.keys : null))
	.flat()
	.filter(Boolean)
	)
	);
	const invalidKeys = Array.from(
	new Set(
	error.data.issues
	.map((issue) =>
	"keys" in issue
	? `${issue.path.join(".")}${
	issue.path.length > 0 ? "." : ""
	}${issue.keys}`
	: null
	)
	.flat()
	.filter(Boolean)
	)
	);

[jaerod95]

doing this will help identify if the issue is from a nested field or a top level field.

[jaerod95]

Not shown in these changes, but to get better error messages for excess fields we'll need to add strict to the zod types in the src/outputs/json.ts file

[jaerod95]

Great work!