Easy generation of multiple types inside same folder

[sp88011]

Feature description

Imagine types are stored in files following this folder structure:

src > parsers > a.ts
src > parsers > b.ts
....
src > parsers > x.ts

Input

yarn ts-to-zod src/parsers/* src/nowIcanValidateEverything.ts

Output

nowIcanValidateEverything.ts has all generated zod types found in any of the files with the path src/parsers/

[fabien0102]

It's a bit harder than it looks since you can have name conflicts in the files (like two export type A = … in a.ts and b.ts)
You should be able to do this easily with a bit of glue, ts-to-zod has a programmatic API, you can see an example here:

ts-to-zod/src/cli.ts

Lines 249 to 256 in 8d3b297

	const {
	errors,
	transformedSourceText,
	getZodSchemasFile,
	getIntegrationTestFile,
	getInferredTypes,
	hasCircularDependencies,
	} = generate(generateOptions);

(you can import generate from ts-to-zod)

[brauliodiez]

Mmm... thinking loud, in my case we use the following naming convention:

Model (entities) files, follow the convention: name.model.ts

Zod schema files, follow the convention: name.zod.ts

So in theory I could just implement some script that traverses all subfolders under src and invoke ts-to-zod does that makes sense?

Thanks for you great tool

[greenpixels]

I actually did the same thing that @brauliodiez suggests, so I thought I'd add a comment here.
I use zod and ts-to-zod for a little web-game side-project using socket.io communication.

I wrote a script for iterating through sub-directories, searching for typescript files and
then creating a zod-schema for it using ts-to-zod:

import { glob } from 'glob'
import { exec } from 'child_process'
import * as path from 'path'

const GLOB_PATTERN = 'dtos/*.ts' // Where to search for typescript definitions?
const GLOB_IGNORE_PATTERNS = ['node_modules/**', '**/*.zod.ts'] // What should be ignored? (*.zod.ts to prevent recursion)
const VERBOSE = false // Should native ts-to-zod logs be printed?
const FILES = await glob(GLOB_PATTERN, { ignore: GLOB_IGNORE_PATTERNS })

FILES.forEach((filePath) => {
    const { base, dir, name } = path.parse(filePath)
    const FILE_PATH_NORMAL = path.join(dir, base)
    const FILE_NAME = name
    console.log(`Generating Zod-Files for ${FILE_NAME}`)
    exec(
        `npx ts-to-zod ${FILE_PATH_NORMAL} ${FILE_PATH_NORMAL.replace('.ts', '.zod.ts')} --config=${FILE_NAME}`,
        (error, stdout, stderr) => {
            if (error && VERBOSE) {
                console.error(error.message)
            }
            if (stdout && VERBOSE) {
                console.log(stdout)
            }
            if (stderr && VERBOSE) {
                console.error(stderr)
            }
            console.log(` ✔ Generated Zod-File for ${FILE_NAME}`)
        }
    )
})

This obviously also matches normal .ts files that are not Types or Interfaces, so if your folder structure has types and modules mixed, you'd need to adjust the pattern, structure or the file names. :)

And you also need to map all your affected files in the correct import-dependency order inside of the ts-to-zod.config.js by hand in order to prevent issues.

/**
 * ts-to-zod configuration.
 *
 * @type {import("ts-to-zod").TsToZodConfig}
 */
module.exports = [
    { name: 'Vector2DTO', input: './dtos/Vector2DTO.ts', output: './dtos/Vector2DTO.zod.ts' },
    { name: 'EntityDTO', input: './dtos/EntityDTO.ts', output: './dtos/EntityDTO.zod.ts' },
    { name: 'ProjectileDTO', input: './dtos/ProjectileDTO.ts', output: './dtos/ProjectileDTO.zod.ts' },
    { name: 'PlayerDTO', input: './dtos/PlayerDTO.ts', output: './dtos/PlayerDTO.zod.ts' },
]

I'm pretty sure you could even, under the right circumstances and project structure, create the configuration on the fly by creating a preprocess step in which you try to figure out the order of the files based on whether or not they have imported another scanned file or something like that. Probably way easier said than done tho. :)

Anyway, really cool project!

[tvillaren]

Thanks for sharing @greenpixels !

Yes, I believe the complexity is in ordering the files based on their imports (and I was actually thinking about generating a config file on-the-fly based on the right ordering).
Once we have it, the rest is already implemented.