Expose `nexus generate` command to produce artifacts without starting the server

[luhagel]

Perceived Problem

Some of our postinstall pipeline depends on an existing schema.graphql file. Back when using @nexus/schema in isolation, this could be generating by running something along the lines of ts-node src/schema.ts. To my knowledge that isn't possible with the nexus cli and running the server only to stop it right again just so graphqlcodegen can run gets old pretty fast.

Ideas / Proposed Solution(s)

Expose a nexus generate command that can be called and, given reflection etc. come up successful, generates all artifacts like the types and graphql schema.

[jasonkuhrt]

IIUC you don't want to commit that SDL file? Just generate on the fly during CI?

We used to have this cli command actually :) CC @Weakky

I assume you don't want to use nexus build because it's too slow? That should technically work though.

@Weakky like we have in dev I wonder if we should have a reflection flag/command for build nexus build reflection.

This however would still do a bunch of work beyond what @luhagel needs... indeed maybe we want to bring back nexus generate sdl. Or avoid adding a top level command yet. nexus build sdl. But technically sdl has nothing to do with build! Maybe it would be confusing to do this. Thoughts?

If we bring back generate top level command I wonder then about merit of replace nexus create ... with nexus generate ....

nexus generate app
nexus generate plugin

Short aliases:

nexus gen app
nexus gen plugin
nexus g app
nexus g plugin

Overall I think I like the idea of consolidating everything under the "generators" concept and just having different kinds of generators. Plugins could add more, for example tight genql integration:

nexus gen genql --a --b ...

Pretty cool!?

[luhagel]

Heya, I really like the generators, especially if it becomes extendable, think scaffolding, generating the corresponding gql type from a prisma model...

For now, committing the sdl is the interim we settled on, but in a Code first approach I see the sdl file purely as an artifact that shouldn't get committed since it doesn't offer much value aside from cluttering PRs (Given of course that the generation works as expected ^^)

[Corjen]

Hi! Just curious, is there an ETA around this? :)

[assertnotnull]

This would come in handy yes. With a clean copy of our project, after doing yarn install the tests(using nexus/testing) show multiple errors from missing interfaces/types but building all the project is not making sense if the tests fail specially that it takes in our case around 70 seconds to build on my laptop.