V8. Generated types location

[ziimakc]

Maybe it makes sense to move generated types into node_modules and expose them like prisma does?

import { Generated } from "graffle/generator";

const data: Generated.UserQuery = {...}

Reasoning:

• No need to commit generated types and commit regenerated types on each new query/schema change.
• Generated types are ugly, unreadable and not formatted :)
• Generated types use PascalCase while backend mostly uses dash-case for file naming.
• It will be simpler.

[jasonkuhrt]

If you install dprint it will be formatted. Regarding file naming conventions I will expose an option for that.

Regarding how Prisma does it, I'm not closed to that however it's more complex for many reasons so wouldn't prioritize it now.

You could emit to node_modules/@types/graffle-generated, but that wouldn't solve the runtime parts that still need importing for some features.

[jasonkuhrt]

Related #1144

[jasonkuhrt]

@ziimakc Let's keep this open for now:

• bring option to control file case
• explore node_modules emit in the future (either as guide content or full blown feature)

[jasonkuhrt]

In order to output to node_modules we would need to consider a few things:

• How the static exports of graffle are modified to accommodate the generation. Literally we'd probably have to rewrite one or more entry points in graffle or that via some indirection.

• How will multiple schemes be supported. we could for example start to append new client entry points:

   import { One } from 'graffle/clients/one'
   import { Two } from 'graffle/clients/two'
   // ...

  This would require a manipulation of the exports field on the package.json as well.

• The really hard part has to do with having the package managers, bundlers, etc. not lose track of the generated contents. I would talk to @millsp. I think you can do something like emit to node_modules/.cache which all package managers will NOT touch. But, we'd still have to write into node_modules/graffle/... to make it attempt to import from there etc. And anything we do there is what becomes fragile. Maybe we could rely on the Node resolution algorithm along with dynamic ESM import, for example ... import('../.cache/...') but then we've lost the static aspect of the library after generation which is not good for tree-shaking etc.