It would be awesome if there was a option to just generate fragments and services side by side with the *.gql files.
This example
[Component A]
- query.gql
[Component B]
- query.gql
resulted in this output.
[Component A]
- query.gql
- query.ts
[Component B]
- query.gql
- query.ts
Then i could define an angular component's specific fragments without worrying about naming collisions, like I needed to do here because some other component's grapql query had a fragment defined with the name location, and the same goes for query and mutation names.
fragment locationSelect on Location {
id
name
}
query GetPositionModalData {
locations: locationsConnection(pagesize: -1) {
edges {
node {
...locationSelect
}
}
}
}
Thanks for the idea @furier !
Do you have any suggestion for the API for this? right now we are specifying a path for the output file, and we also need to find a solution for referencing files for imports. We had a similar approach in the older versions (called MULTIPLE_FILES), and we dropped it because it was hard to maintain, and had a lot of issues.
What about something like this? Where you just place a generated file side by side with every match from documents. It would be just the same as if you manually added every single file under generates, but that is tedious to do with hundreds of files, unless i build a tool to generate the config. :P which when I think about it I could do...
schema:
- schema.json
overwrite: true
config:
avoidOptionals: false
generates:
'./src/app/**/*.ts':
documents:
- './src/app/**/*.gql'
plugins:
- 'typescript-common'
- 'typescript-client'
- 'typescript-apollo-angular'
To begin with it could be a requirement that you cant use stuff in the *.gql file that is not defined within the file, so every file would be self contained, no references to other stuff, just imports like gql and gql-tag and other stuff required by the typescript generated client to work.
I think it would be great if this feature was added. 😃
The apollo command creates a type definitions at the query defined location. I think this can be good reference.
```text
USAGE
$ apollo client:codegen [OUTPUT]ARGUMENTS
OUTPUT
Directory to which generated files will be written.
- For TypeScript/Flow generators,
this specifies a directory relative to each source file by default.
Any update on this feature?
I would be really helpfull, right now I manually adding the config to file, is there a better way of doing this?
Any update on this feature?
I would be really helpfull, right now I manually adding the config to file, is there a better way of doing this?
that seems quite cumbersome when you have a lot of components, like hundreds to manually configure all in the codegen.yml file, but I thought of the same thing but let it be until this feature becomes available. Will just have to uniquely name everything until then.
@furier It is sadly.
I am thinking if for the time being I should actually generate the codegen.yml via a file watcher adding the entries auto.
But before doing soI would like to know if its actually in the road map and if possible any estimations.
I would absolutely love this feature.
The main benefit is it allows us to maintain LIFT principles in our codebase. As a workaround I created a path entry in the tsconfig:
paths: {
'gql-types': './generated-types.ts'
}
Imports within the codebase are at least consistant.
import { myServiceGQL } from 'gql-types';
Here's how I've solved this in my codebase:
Rather than using the graphql-code-generator CLI with a wildcard for all my documents, I run it using the API, once for each document:
(async function() {
const files = await globPromise('./src/**/*.graphql');
await Promise.all(
files.map(filename => {
const parsedPath = path.parse(filename);
return generate({
overwrite: true,
schema: ['../graphql-schema.graphqls'],
documents: filename,
generates: {
[`${parsedPath.dir}/${parsedPath.name}.generated.tsx`]: {
plugins: [
'typescript-common',
// ...,
]
},
},
});
}),
);
})();
It's a new project so I have very few documents at the moment, and I haven't seen how well it scales yet.
@furier @adam1658 @vreality64 @Morphexe It took some time, but it's available (as alpha) now after this PR: https://github.com/dotansimha/graphql-code-generator/pull/1846
Great news @dotansimha
perfect!! Thank you!
On Tue, May 14, 2019 at 3:14 PM Sander Struijk notifications@github.com
wrote:
Great news @dotansimha https://github.com/dotansimha
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotansimha/graphql-code-generator/issues/1116?email_source=notifications&email_token=AEJIF46W4JCAUP6NEMOYGPLPVLCNBA5CNFSM4GNGKDZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVLTTLQ#issuecomment-492255662,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEJIF46MFAFWGIQJF3NGR2TPVLCNBANCNFSM4GNGKDZQ
.
Available in 1.2.0.
Most helpful comment
Here's how I've solved this in my codebase:
Rather than using the graphql-code-generator CLI with a wildcard for all my documents, I run it using the API, once for each document:
It's a new project so I have very few documents at the moment, and I haven't seen how well it scales yet.