Version Mismatch of Sinclair's Typebox Causing Type Errors in ElysiaJS

[LeventHAN]

What is the problem this feature would solve?

The problem is that when using Sinclair's Typebox across multiple packages within a monorepo, such as in a shared package for defining types, a version mismatch between the Typebox version used by ElysiaJS and the one installed in the shared package can lead to TypeScript errors. Although the functionality may work as expected, these type errors create a poor developer experience and can lead to confusion or bugs if not addressed. Matching the Typebox versions between ElysiaJS and the shared package resolves these TypeScript errors, ensuring compatibility and a smoother development process.

Original issue was asked in Discord here a copy+paste of it;

So I have an turborepo where I share my types in a shared package. In that package I installed sinclair's typebox with the intention to use the schemas in my elysiajs app and static them to typescript types to use them in my nodejs backend.
So it works just fine but I keep this annoying error;
Functionality is as expected however I can't get rid of the ts error

What is the feature you are proposing to solve the problem?

1. Refactor the checker/validation on ElysiaJS side: Find the source of what causes this error and refactor the way the check is done.

2. Provide Clear Versioning Guidance: Alternatively, ElysiaJS could enhance its documentation to clearly state the required Typebox version, including warnings about potential issues with version mismatches. Additionally, providing a tool or command to check for version compatibility within a monorepo setup could be beneficial.

3. Automatically Align Typebox Versions: ElysiaJS could include a mechanism to automatically detect and align the version of Sinclair's Typebox with the version used in the user's project. This could involve checking the installed Typebox version and either throwing a clear error or warning if there is a mismatch, or automatically resolving to the compatible version.

This feature would ensure compatibility between Typebox versions, eliminating the TypeScript errors and improving the developer experience when integrating Typebox schemas in ElysiaJS applications.

What alternatives have you considered?

1. Manual Version Synchronization: One alternative is to manually ensure that the Typebox version used in the shared package matches the version used by ElysiaJS. This approach involves keeping track of ElysiaJS updates and adjusting the Typebox version accordingly. While effective, this is prone to human error and can become cumbersome in larger projects with frequent updates.

2. Peer Dependency Management: Another alternative is to define Typebox as a peer dependency in the shared package. This way, the responsibility to install the correct version of Typebox falls on the user of the package. However, this doesn't fully solve the problem, as it still requires manual oversight to ensure version alignment.

3. Using TypeScript Type Assertions: We could also address the TypeScript errors by using type assertions or as casting within the code to force TypeScript to treat the mismatched types as compatible. While this would suppress the errors, it doesn't address the root cause and might introduce potential type safety issues, reducing the overall reliability of the codebase.

4. Wrapper Functions or Utilities: Another alternative is to create custom wrapper functions or utilities that abstract the Typebox usage, ensuring that all type manipulations go through a controlled interface that handles or mitigates the version discrepancies. While this could work, it adds extra complexity to the codebase.

Each of these alternatives has drawbacks, particularly around maintainability and complexity, which is why a built-in solution in ElysiaJS would be more beneficial.

[masterT]

Related to #690.

[abhi-slash-git]

Would be nice to not have this workaround.

[m1212e]

Superforms is an example where exactly one patch version is off which leads to different versions of typebox installed in the modules and therefore a different reference which causes this TS error:

elysias package.json

	"peerDependencies": {
		"@sinclair/typebox": ">= 0.32.0"
	},
	"dependencies": {
		"@sinclair/typebox": "0.32.34"
        }

superforms package.json

	"peerDependencies": {
		"@sinclair/typebox": ">=0.32.30 <1"
	},
	"optionalDependencies": {
		"@sinclair/typebox": "^0.32.35"
	}

If there isn't a specific functionality in the pinned version which elysia relies on a version range would be a good option!