Preserve @ts-expect-error directives

[alecmev]

As mentioned in #659 (comment), some prefer to keep skipLibCheck off. It's not about being pedantic, it can help explain otherwise cryptic errors (speaking from experience), and puts pressure on the ecosystem to keep their types clean.

However, in this case it isn't an easy fix at all (looks like QuestionMarkSchema being recursive pushes the limits of inference, microsoft/TypeScript#30134, microsoft/TypeScript#47599). Hit my head for half an hour, to no avail.

Thankfully, this repo already has // @ts-expect-error peppered throughout:

valibot/library/src/types/other.ts

Lines 90 to 99 in 094d984

	export type QuestionMarkSchema =
	| NullishSchema<BaseSchema<unknown, unknown, BaseIssue<unknown>>, unknown>
	| OptionalSchema<BaseSchema<unknown, unknown, BaseIssue<unknown>>, unknown>
	// @ts-expect-error
	| LazySchema<QuestionMarkSchema>
	| NonNullableSchema<
	// @ts-expect-error
	QuestionMarkSchema,
	ErrorMessage<NonNullableIssue> | undefined
	>;

So all that needs to be done is just preserve these in the emitted .d.ts. Easier said than done, as I haven't been able to find if tsc can even do it, but worst case, at least it could be a post-build script just adding these back in above QuestionMarkSchema and QuestionMarkSchemaAsync, and inside of TuplePath.

[fabian-hiller]

A better solution would be to figure out how to avoid the recursive inference problem. If we can't find a solution, we could try to limit the recursiveness to a certain depth. Are you interested in exploring this problem?

[alecmev]

Done 😉 #778

[fabian-hiller]

Related issue at the TS repo: microsoft/TypeScript#38628

[alecmev]

Good find! Looking at that issue, how about /** @ts-expect-error */? TypeScript preserves doc comments.

[fabian-hiller]

This may work, but it is a dirty hack. I would prefer an official solution, or that we rethink our implementation. But I will consider it.

[fabian-hiller]

This will probably be fixed in the next version.

[fabian-hiller]

v0.38.0 is available 🚀