Blitz: Architecture: Extract generator and console out of cli

[ryardley]

What do you want and why?

We should extract the generator and to a lesser extent the console out of the cli package to their own packages or at the very least folders

• Both represent pieces of code with very separate usage scenarios
• Both are currently mixed up with oclif and need not be
• Separating input argument parsing from task execution makes sense as we may want to expose a node API for either component in the future
• Both are sharing a utils folder containing context specific functionality that should be kept separate
• Groking the code it is hard to see what code belongs to which code area
• If we were to remove or swap out oclif at a later date it would be much easier should these be in separate packages.

Possible implementation(s)

@blitzjs/generator
@blitzjs/console

[aem]

I forgot this issue existed. @blitzjs/generator exists now, we still need someone to pull out the console code

[peaonunes]

I'm happy to try pulling out the console got. Looking at the codebase its just one file, but it depends on runPrismaGeneration which is owned right now by the /commands/db.ts (and also used by the start.ts command). Not sure if it should be shared by those files, should we:

• move this function to a shared package before doing it?
• keep the function as it is and make console package get the function from commands package?
• duplicate the logic inside the console package
  🤔

[aem]

my personal thought is duplicate the logic for now. I assume at some point we'll want a shared @blitz/prisma package that we can use to centralize all of our prisma code, but I don't think we have enough information to know what that shared API needs to look like so better to duplicate rather than choosing the wrong abstraction.

@ryardley @flybayer thoughts?

[flybayer]

The prisma code will be in a plugin like blitz-plugin-prisma or something.

Ok to duplicate for now, but add a comment both places clearly stating this.

[peaonunes]

I've the same feeling about it.
I like the plugin idea, right now the db is tightly coupled with prisma which would be hard to switch/replace implementation if needed. I guess the ultimate goal would be to have an decoupled db module where you could plug in and out any database provider. Perhaps that could be another work front since it is a long way until having that abstraction.