Add configuration to reference different `.graphql` source file locations

[NeedleInAJayStack]

[GNMoseke]

I've been tinkering with this locally, and it seems sadly to be not as trivial as it should be. The main problem boils down to the fact that there's no way (AFAIK) to provide a custom piece of metadata/config to a build plugin, you only have access to the PluginContext and by extension Package structs, and then the Target protocol, none of which provide any way to pass through a setting like

targets: [
    .target(
        name: "YourTarget",
        dependencies: [
            .product(name: "GraphQL", package: "GraphQL"),
            .product(name: "GraphQLGeneratorRuntime", package: "graphql-generator"),
        ],
        plugins: [
            // this would be neat but alas
            .plugin(name: "GraphQLGeneratorPlugin", package: "graphql-generator", config: ["gql-schema-path": "/some/other/place"])
        ]
    )
]

There's a couple workarounds that occur to me:

1. Allow the path to be given by a good ol' env var a-la GQL_SCHEMA_PATH=/some/other/gql.schema swift build
2. Introduce some sort of custom config file format for the plugin, like a gql-generator.yml that gets read by the build plugin as well if possible. I hate this on principle.
3. Expose the GraphQLGeneratorPlugin as a command() in addition to a buildTool(), which then of course lets a user manually give whatever paths they want when they invoke the subcommand, just adds the manual step in the more complex case.

(1) seems the most reasonable to me in terms of keeping it as a build plugin (way more convenient) but it does mean that changing the source location isn't declared anywhere in source/Package.swift (though obviously someone could put what the want in a makefile/justfile/etc).

Lemme know if you already had a solution in mind for this though, I mostly just wanted to play with swift plugins because I haven't touched them in a while and they have lots of shiny new stuff

[NeedleInAJayStack]

Hey Garrett! Thanks for taking a look and thinking about this!

Lemme know if you already had a solution in mind for this

I haven't done any development around it, so you've definitely gotten farther than I have. I definitely agree - I wish we could have a more programmatic API to modify the plugin's behavior. However, I was thinking of taking a similar approach as swift-openapi-generator (documented here), which is basically your (2). I think the config file does have some advantages:

1. Consistent builds for a given checkout, whereas environment variables can well... vary from... uh... environment to environment. Groundbreaking insight, I know.
2. A nice central place to grow as we expand our config over time
3. It seems to have worked alright for swift-openapi-generator!

Anyway, let me know your thoughts - I definitely haven't explored the details.

[GNMoseke]

I had not seen how swift-openapi-generator does it, it does seem decent. You know that I have a frothing hatred of yaml so take my opinion with a grain of salt obviously:

• My biggest hesitation is introducing an additional file deep in the source tree, this is largely a personal thing but I prefer all of that stuff to be as close to the root as possible. There may be a way to do that here anyway so it may be a non-issu.
• I do think if a config file is the way to go it should not be required (at least not initially). The reproducibility is good but requiring an extra setup step for what I assume to be 90% of the time the "simple API case" seems unnecessary, the existing sensible default of "find all graphql source files in the target source tree" seems like it will cover most standard use.
• In a point of favor to config file format though, it would be sweet to be able to define different configs for different targets in that way. I highly doubt that would be a common use case, but for big monorepos with multiple GQL APIs maybe.

I'm probably thinking too much about it here. I do think in a perfect world you could define settings in Package.swift and that gets you the reproducibility per checkout + per-target config + single manifest file source of truth, but since that's currently not possible as a language limitation so be it.

The new swift-configuration library also could be useful (though I bet you already had that in mind) and that takes away my personal distaste for yaml as well.

[samisuteria]

The way https://github.com/apple/swift-protobuf handles it with a configuration file https://github.com/apple/swift-protobuf/blob/main/PluginExamples/Sources/Import/swift-protobuf-config.json in the sources folder seems to be a common approach for idl -> codegen. https://github.com/grpc/grpc-swift-2 handles it the same way too. This is also I handle it in my own GraphQL schema generator https://github.com/NoDevOrg/GraphQLTools. Happy to chat more about it