Handle multi-file types

[abaco]

As suggested in the README, I'd like to express my wish for multi-file types support.

My use case is the validation of data for React components. The types are simple, but spread over many files because each component lives in a separate file and defines the type it expects as input. I only need to validate data for root (page) components, which contain a deep hierarchy of descendant components.

[abaco]

@vedantroy I may have some time to work on this, if it's not a huge effort. Do you already have ideas on how to proceed?

[vedantroy]

I'd love if someone worked on this!

It might be complex though. Here's why multi-file types don't work right now: kentcdodds/babel-plugin-macros#155

I think the easiest thing to do in the case of multi-file types is to write all the type validation functions into a single file at the end in one pass. Individual files can then import type validation functions from the generated file.

The above could potentially be implemented by using the work-around present in the linked Github issue.

This could also avoid the need for a CLI tool, since we can do this in the macro itself. I think this would require a decent chunk of work, but would def. be do-able.

A more complex system would be to have a proper CLI tool that first parses all the files with Babel (in order to get information about multi-file types), and then emits the files with the type validation functions filled in the correct places.

However, I think if a full-CLI tool is built, then it would be better to use the TS compiler API / create a TS transformer & just re-use the code-generation part of this project.

This project duplicates a lot of the things Typescript does (instantiation of generics / implementation of intersection & union operators) because it wants to be a Babel macro to be used as easily possible. However, if this project was turned into a CLI tool, then there's no reason to use a hand-rolled type system.

[cmrigney]

Is there a way to ignore external types?
Like

import { Tail } from './Animal'

interface Cat {
  color: string;
  tail: Tail; // ignore, don't validate this
}

[cannd]

Is there a way to ignore external types?
Like

import { Tail } from './Animal'

interface Cat {
  color: string;
  tail: Tail; // ignore, don't validate this
}

You can work around by adding

{

  type Tail = object

  registerType('Tail')

}

before interface Cat's declaration (note the block scope. And defining Tail as any/unknown/empty interface doesn't work, as of current version)

And then you can use Tail's validator as a constraint in Cat, something like
createValidator<Cat>(undefined, { constraints: { Tail: x => tailValidator(x) } })

It's a bit harder to get the error messages right for createDetailedValidator though.

[klippx]

We also would love to see this use case solved. We want the backend to guarantee that the responses have shape as per the exported response types. This response type declaration is supposed to be imported by the Front end.

But with a lot of handlers / endpoints it gets a very messy to have one monolithic file to cram all typings into. We need to make room for both Request interfaces, Response interfaces for each endpoint which can also have more than one response shape (e.g. in case of error).

Since endpoint code is usually colocated it would be awesome if the typings could also be colocated, but for that to work they need to be able to import certain common type definitions.

Right now the two alternatives are

1. monolithic file
2. colocating code, and avoiding imports by repeating type definitions everywhere. bad idea right, since they would be getting out of sync

This is one drawback to start using this lib as we are currently investigating libs to use.

[dimaqq]

I too would like multi-file types, though for a different reason.

I use codegen (for an openapi spec), and I'd rather not edit the generated files 🤷🏿
Additionally that specific tool generates one type per file, and thus compound types necessarily span several files.

[meikidd]

Thanks for your great work @vedantroy . We would love to have the multi-file types supported.

[vedantroy]

These are all good concerns, and I'd love to implement multi file types. Alas, I just don't have the time anymore. I've looked around for maintainers, but I haven't really found any. If anyone on this thread (@dimaqq , @meikidd , @klippx ) would want to take a stab at implementing them, I'd be happy to give guidance / assistance, but I can't pull this through on my own.