ardatan / graphql-import

Import & export definitions in GraphQL SDL
869 stars 56 forks source link

Typescript *.graphql baking #52

Open iamlothian opened 6 years ago

iamlothian commented 6 years ago

I am trying to make use of graphql-import with typescript, It loads files fine but I still have to find a way to copy the .qraphql files to a dist folder... which mean involving some more complex build steps. And the idea of maintain both a *.graphql version and *.graphql.ts version is not ideal.

While I haven't considered all the other existing proposals and how they might solve this, I'm considering trying out something like the following, to achieve the functionality i desire: Folder structure for a singe entity

- Book
-- index.ts
-- query.qraphql
-- query.qraphql.ts
-- resolver.ts
-- schema.qraphql
-- schema.qraphql.ts

*.qraphql.ts

import { importSchema } from "graphql-import"
export const Query:string = importSchema(__dirname + '/' + __filename.replace('.ts',''));

when I build i want to take the *.qraphql content loaded and replaces the importSchema with the actual graphql schema/query string. so that the dist folder will contain a baked version of the graphql schema/query at build time.

Thoughts?

EDIT: Better yet, potentially I can build cli tool that makes use of this module to watch files and bake them into .js / .ts files that export the graphql schema/query string on change.

kbrandwijk commented 6 years ago

You can use the prepare command from graphql-cli to process the schema imports at build time, and save a .graphql file with all the imports processed.

iamlothian commented 6 years ago

@kbrandwijk, Thanks, and sorry if i wan't clear, I just made an EDIT as you posted your response.

I have found the graphql-cli documentaion a bit shallow, in terms of defining the proper use case in a project.

I'll admit that some parts of the graphql ecosystem are still a little unclear to me so it's possible i'm thinking about this the wrong way, correct me if this seems like a ludicrous idea. I'm looking to go the other direction. I want to maintain *.graphql and have a .js / .ts file generated that i can import into my src to be used by the server.

kbrandwijk commented 6 years ago

@iamlothian Thank you for clearing that up. Currently, there are two main components. There's graphql-import, for processing import statements (.graphql in, .graphql out), and there's graphql-static-binding, used to create and ORM-like class (js or ts) based on your .graphql schema for easy use in your code.

Some of the generators used for the bindings also include the schema in the .js/.ts file. And if there's a use case to add them to other generators, I'd be happy to do so.

This will give you a .js/.ts file that exports both the schema, and the typings and an ORM class. Would that fit your usecase?

You could use nodemon to watch for changes in your .graphql files and rerun the prepare command to generate your .js/.ts file.

iamlothian commented 6 years ago

@kbrandwijk Thanks, that does sound like what i'm looking for. Let me do a little catch up reading before I suggest adding or building something new.

EDIT: I'm not sure bindings is what i am looking for, that seems like more of a client helper than a server tool.

In my server I want to separate the graphql definitions for related types, queries and resolvers into their own folders and files, as shown in the book example above. The graphql-cli seems to be interested in maintaining a single schema.graphql file, as do most of the IDE integrations. This seems like a rather unassailable solution. A mature intellicence tool should be able to grab all the distributed files and make scene of them to provide autocomplete and error correction.

testing the graphql-cli prepare with a simple schema.graphql:

  type Query { books: [Book] }
  type Book { title: String, author: String }

resulted in no errors and no output, I'm not sure what the expected bindings should have been so if this is a bug I'll log it over there.

The goal is to gather all of the graphql files and resolvers and give them to makeExecutableSchema the be served via apollo-server-express. I feel like this would be a neat way to maintain a project as it grows.

locnguyen commented 6 years ago

@iamlothian I just started a TS based server project and have the same directory structure as you do. Was wondering if I could define my schema in *.graphql files too and landed here. Did you find a solution?

iamlothian commented 6 years ago

@locnguyen not yet, haven't had a chance to attempt to build something yet. It might be something i look at forking into the graphql-cli.

Alternatively if you can be persuaded to use webpack on your server code you can use graphql-tag

Update: I have successfully made this work using webpack and graphql-tag loader, using the typescript compiler alone would have been preferable, but I think i'll run with this solution for now.

decebal commented 4 years ago

it appears that most of the community went for a simple cp of files into the dist folder.. webpack seems to me like quite an overhack, although I tried it and works, my latest work does not need any webpack aside from this so reluctant to include it when easy to avoid by copying files.