Open mweststrate opened 5 years ago
For example: https://github.com/dotansimha/graphql-code-generator
@jamonholmgren's https://github.com/infinitered/gluegun does templating well.
Thanks for the mention, @sw-yx!
We're using the ejs
library to power our template system:
We also have a really cool patching library:
Both are built-in to Gluegun, which may be overpowered for your needs here. But if you want to make mst-gql
a full featured CLI, let me know and I can walk you through what you get with Gluegun! Otherwise, feel free to steal/borrow any concepts from the links I posted here.
Should we actually turn this into a monorepo to split stuff into plugins? I am no big fan of Lerna, it does the job, but it also gets in the way fairly often.
Let's not over engineer yet; it does make contributing harder
Op wo 29 mei 2019 11:10 schreef Daniel K. notifications@github.com:
Should we actually turn this into a monorepo to split stuff into plugins? I am no big fan of Lerna, it does the job, but it also gets in the way fairly often.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mobxjs/mst-gql/issues/13?email_source=notifications&email_token=AAN4NBFMTAUJ6RGM7EG47LDPXZCBXA5CNFSM4HP6IHHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWOWD6Q#issuecomment-496853498, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN4NBF7DC24PCM3LI6OTRDPXZCBXANCNFSM4HP6IHHA .
Ok sure, I suppose that Gluegun can use "plugins" from the single package, so that shouldn't matter, but we should also support custom plugins from NPM.
Regarding the code generation, I actually do have a custom generator for graphql-code-generator
which generates fully typed hooks for each graphql operation. I am not sure yet how it would look like here, but a similar alternative would be really nice.
export function useQResolveLocation(
variables?: QResolveLocationVariables,
baseOptions?: Hooks.QueryHookOptions<QResolveLocationVariables>,
) {
return Hooks.useQuery<QResolveLocationQuery, QResolveLocationVariables>(
QResolveLocationDocument,
variables,
baseOptions,
)
}
I am using prefixes Q, M, S, F for my *.gql
documents and based on that I can distinguish those easily.
Please open separate issues for separate ideas 😉
Op wo 29 mei 2019 11:58 schreef Daniel K. notifications@github.com:
Ok sure, I suppose that Gluegun can use "plugins" from the single package, so that shouldn't matter, but we should also support custom plugins from NPM.
Regarding the code generation, I actually do have a custom generator for graphql-code-generator which generates fully typed hooks for each graphql operation. I am not sure yet how it would like here, but a similar alternative would be really nice.
export function useQResolveLocation( variables?: QResolveLocationVariables, baseOptions?: Hooks.QueryHookOptions
, ) { return Hooks.useQuery<QResolveLocationQuery, QResolveLocationVariables>( QResolveLocationDocument, variables, baseOptions, ) } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mobxjs/mst-gql/issues/13?email_source=notifications&email_token=AAN4NBBLK2IHEEFXEKSAZA3PXZHUDA5CNFSM4HP6IHHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWO2HFQ#issuecomment-496870294, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN4NBGIXXRSH3VPBBI5YETPXZHUDANCNFSM4HP6IHHA .
I just want to add that kotlin/java poet might be a good source of inspiration: https://github.com/square/javapoet and https://github.com/square/kotlinpoet . I love that library. It uses builders to generate the code, instead of dealing with a template engine. The builders take care of indentation, importing types and injecting formatted variables with c-style literals. Writing code generator logic can get quite messy quickly, and java poet does a great job of keeping it under control. Unfortunately, I didn't find any equivalents in JS. The most similar lib that I've found so far was ts-morph
Would love to help out with this.
Gluegun definitely looks promising (especially the patching could be great). I've also used Plop which was quite simple to understand and Hygen looks promising.
@dpnolte ts-morph looks like "the proper way" that you would want to do code generation by using the AST. However, reasoning about AST's gets quite complex quickly and can be difficult for newcomers to understand. Since most of the code will be auto-generated and provide convenient hooks for people to extend it means we already have a great deal of control over some of the foundational assumptions and as such we could just work on those with simpler file templating and "patch comments" for us to use.
I think we should make a decision on this rather soon before we end up adding a bunch of code that becomes difficult to port. @mweststrate did you already have a direction in mind?
Nope! I think the person giving this a shot is in the best position to judge :). But yeah, I agree that the AST direction is most probably adding unnecessary burden
On Mon, Sep 30, 2019 at 12:17 PM Rik notifications@github.com wrote:
Would love to help out with this.
Gluegun definitely looks promising (especially the patching could be great). I've also used Plop https://github.com/amwmedia/plop which was quite simple to understand and Hygen https://github.com/jondot/hygen looks promising.
@dpnolte https://github.com/dpnolte ts-morph looks like "the proper way" that you would want to do code generation by using the AST. However, reasoning about AST's gets quite complex quickly and can be difficult for newcomers to understand. Since most of the code will be auto-generated and provide convenient hooks for people to extend it means we already have a great deal of control over some of the foundational assumptions and as such we could just work on those with simpler file templating and "patch comments" for us to use.
I think we should make a decision on this rather soon before we end up adding a bunch of code that becomes difficult to port. @mweststrate https://github.com/mweststrate did you already have a direction in mind?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mobxjs/mst-gql/issues/13?email_source=notifications&email_token=AAN4NBA2GXIJCQ4HO4W7SPDQMHN27A5CNFSM4HP6IHHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD75JSBY#issuecomment-536516871, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN4NBEUT3CSL7VUPCLDWFLQMHN27ANCNFSM4HP6IHHA .
Ok, but then I'll give it a shot with Gluegun next week. I'll probably first just spit out a few ejs templates not worrying too much about the actual data. And then put up a bit cleaner framework for the CLI & logging. Hopefully, then others can join in to help fill in the actual template data as I expect that requires a bit of knowledge of how it is currently generated.
I would prefer writing everything in Typescript if that's ok with everyone?
yes please on typescript :)
@RXminuS npx gluegun new mst-gql --typescript
will get you set up with an initial TypeScript boilerplate. Hit me up if you run into problems. I'm happy to knock out bugs fast on Gluegun. I just released 4.0.0 which needs more testing, so let me know. Also any documentation gaps.
@RXminuS do you have any progress with this?
I myself would like to have the options provided by https://graphql-code-generator.com/docs/plugins/typescript, which allow changing the case of type names/enums and getting rid of underscores in type names in generated code.
It uses a configuration like this:
config:
namingConvention:
typeNames: change-case#pascalCase
transformUnderscore: true
I thought I add such options to the current generator but if there's already a better one in progress I would rather work with that.
The current generator
generate.js
, is a pretty straight forward string concatenation tool. it's fast and straight forward, but probably not very maintainable as it grows more complex in the future. Something more solid could be a good idea, I think @birkir had some thoughts about that in the past