Type-graphql: CLI tool

[MichalLytek]

I am thinking about creating a CLI tool - its features, capabilities and usefulness. Few ideas are in my head right now:

Basic:

• init command to create base configured app skeleton from boilerplate repo
• init command with more detailed config (folder per type/feature, etc.)
• automatic generation of resolver and type classes and files
• automatic generation of CRUD resolvers from object type classes

Advanced:

• types generation - create a template to generate complicated derived types from model, ex. filter or where inputs
• SDL converter - generate TypeGraphQL project with types, args, input and resolvers based on schema.gql file with SDL

:speech_balloon: Other proposals:

• integrate with typeorm-model-generator or other way for generatic object types from db (@omatrot)
• ~exporting the graphql schema from classes (@omatrot)~ done in #170

[laukaichung]

Will it generate typescript definition files like graphql-code-generator or apollo-codegen?

[MichalLytek]

Typescript definition files of what? All the schema is defined by code, for all your client queries you can use apollo-codegen.

[useless-stuff]

Hello!
type-graphql it's exactly what I was looking for, nice project! :)
A couple of days ago I've started a project for managing AWS AppSync with Serverless and Typescript.
I'd like to use type-graphl as core package for managing code and I'd like to be involved in your project :)

I've invested a bit of time to figure out which libraries and tools people are using out there in order to create a solid and cross-platform CLI.

Basically, this is the packages stack:

• commander: A complete solution for node.js command-line interfaces.

• inquirer: A collection of common interactive command line user interfaces.

• ShellJS: Portable implementation of Unix shell

If you think that I can help somehow, just let me know I'll be happy to work on the CLI or other stuff.

You can find a very basic example that I did last night:

https://github.com/useless-stuff/lakitu/blob/feature/cli/src/lakitu.js

Do you have any Slack channel for this project?

[MichalLytek]

Thanks for the research about tools for creating the CLI 😉 I will definitely take a look at them when I start working on this, for now I have to think and collect CLI feature ideas.

There is gitter for questions and discussions not related to issues, mostly due to nice github integration:
https://gitter.im/type-graphql

[omatrot]

Another idea : add the ability to export the graphql schema from classes.

[MichalLytek]

Right, it might be an option. It's just calling printSchema from graphql after buildSchema from type-graphql but it would impose specific folder/files project structure.

[kn0ll]

i saw similar comments in https://github.com/19majkel94/type-graphql/issues/81- regarding printSchema.

i think a decent solution might be to expose the printSchema example you provided as a command line tool-- except allow it to accept a module path and output locations as arguments (and that module path would resolve to a schema). something like (pseudocode... not thinking too hard...)

// createSchema.ts (created by user)
export function createSchema() {
  return buildSchema({
    // ...
  }
}

// print-graphql-schema.ts (exposed as type-graphql command line tool)
const createSchema = require(process.argv[0]);

(async () => {
  const schema = await createSchema();
  const sdl = printSchema(schema);
  // or stdout...
  await fs.writeFile(process.argv[1], sdl);
})();

// then i can do...
$ print-graphql-schema ./createSchema.ts ./graphql.schema

i suppose you could argue that despite it's size this could still really just be it's own separate NPM module-- but it does seem like something most users of type-graphql will require (assuming they are writing their own clients).

if you're interested in a PR it's straight forward / isolated enough that i'd be comfortable giving it a shot.

[MichalLytek]

There are two ways of how to make CLI works:

• typegraphql.config.json (like ormconfig.json) where users set the resolvers and other options and could be automatically implicitly use by CLI and buildSchema
• your solution, where there's need to conform the interface like a module file with default export of function that return a promise of GraphQLSchema
  They both have pros and cons so it might be better to implement them all, so users could choose which options fit them best 😉

Thanks for your suggestion, I will take it into account in the future when the base CLI core will be ready - I will provide some docs how to add custom plugins/commands in own project or as a PR to the main repository.

[ematipico]

Are there any updates about this? I would like to give some help, maybe starting proposing a prototype

[fullofcaffeine]

+1 interested in the crud mainly for the CRUD boilerplate