typia
typia copied to clipboard
Feature Request: Elide typia import so typia can be in devDependencies
Feature Request
A description of the problem you're trying to solve.
After compiling a literals<Type>() the type is compiled to an array, but typia import remains. This necessitates typia be installed during runtime
An overview of the suggested solution.
Remove typia import after compiling (if possible, don't know if there are some typia features that require typia be imported during runtime
Unfortunately, don't know how to \o/.
To accomplish this suggestion, typia have to visit every node elements in the TypeScript file.
If someone can do it, hope him(her) to try this issue.
related - https://github.com/samchon/typia/issues/678
use bundlers that can tree-shake typia
@KristjanTammekivi We have two choices, maybe
- split
typiainto runtime & compiler (like@typia/runtime@typia/compiler), so that we can reduce installing size - bundle typia runtime using bundlers &
unplugin-typia. I'm working on tree-shaking in this couple of moths,(https://github.com/ryoppippi/thesis-benchmarks/tree/feature/update-and-rollup)
I think bundling typia's runtime is good enough
In development mode, the generated code should be simple and clear.
If the user wants to reduce the size of the build in the prod, he will use some kind of bundler, a minifier, etc.
Accordingly, the generated code should be suitable for bundlers.
To do this, you need to use treeshake annotations, modular source code, etc.
You can put all the constants, functions used, etc. into one separate file (or virtual module), from where they will be imported. Also, all generated functions will be almost empty and will use only imports.
Thus, there will be no duplication, the bundler will remove unnecessary code, optimize the rest and the problem will be solved.
Or something like that.
For me bundling is as much of a hassle as just having typia as a runtime dependency.
Splitting the package would work for me as long as all compiler imports are removed but I'm guessing it's too much work to just to help out one little use case.
@KristjanTammekivi but in this case, other libraries are same. Zod is big, valibot has 1.45 MB size.
This is my opinion(not @samchon 's), but if you want to skip build step, typia is not appropriate choice for your project. For example, we cannot use Typia in Deno without bundlers because Deno does not have bundler-plugin modules. In this case we need to choose other validation libraries like zod.
Just figured this out yesterday, forgot to add here. Solved by adding an extra transform after typia to remove the import.
import type * as ts from 'typescript';
import type { TransformerExtras, PluginConfig } from 'ts-patch';
export default function (program: ts.Program, pluginConfig: PluginConfig, { ts: tsInstance }: TransformerExtras) {
return (ctx: ts.TransformationContext) => {
return (sourceFile: ts.SourceFile) => {
function visit(node: ts.Node): ts.Node | undefined {
if (tsInstance.isImportDeclaration(node)) {
const moduleSpecifier = node.moduleSpecifier as ts.StringLiteral;
if (moduleSpecifier.text === 'typia') {
return undefined;
}
}
return tsInstance.visitEachChild(node, visit, ctx);
}
return tsInstance.visitNode(sourceFile, visit);
};
};
}
(typia wasn't used for validation so other libraries don't apply)
@KristjanTammekivi you can send it as a PR! Nice.