Idea: Allow injecting code in the end of .gen.js file to enable comparing of imported types to generated ones

[Tomi Saarinen]

Rationale: It seems at the moment it's possible to import types from flow/ts source files but ReScript doesn't really know what they contain. It is also possible to generate flow/ts types with genType based on bindings or actual code. However it's not easy to compare the imported types to generated ones to make sure changes in flow/ts codebase keep getting reflected in bindings accurately

How about if it would be possible to manually add such "safety net" by using the flow/ts engine to do the work like this:

// First we import the types as they are defined in the original source
@genType.import("MyFlowOrTSComponent")
type importedProps

// Then we create bindings to that same component based on our understanding of the ReScript types 
@bs.module("MyFlowOrTSComponent") @react.component
external make: (
  ~id: string,
  ~name: option<string>=?,
) => React.element = "default"
export default = make

// Finally we add some custom code to cause error in flow/ts if the types mismatch.
// Note that this can be arbitrary relaxed or strict and it can utilize all features available in flow/ts.
@genType.appendRaw(`
let map = (props: importedProps) => (props: Props)
`)

The last map function will cause flow/ts error if importedProps do not match to generated Props anymore. I doubt there is a generic solution to this, but allowing any flow/ts types/code would allow the developer to implement what they feel is necessary.

Ps. It might be possible to do this by importing the genType generated types into the flow/ts files and doing the work there but I feel like it might either cause import loops or at least force the developer to create extra files just for this purpose.

Any thoughts? Maybe it's already possible to achieve the same safety in some other way?

[Cristiano Calcagno]

This is what @genType.import does: it generates code for the only purpose that it does not type check if there's a type mismatch.
That said, there are types that don't map over cleanly (e.g. anything that corresponds to a class). Perhaps for those cases, an escape hatch such as raw could help. Though, there's no guarantee that such a raw code stays up to date. E.g. one could change make and forget to adapt the raw string.

[Cristiano Calcagno]

No immediate plans for this. But if there's a specific proposal + use case, feel free to reopen.