Add Preserve rewrite Config to Opt-out of breaking single-file resolver always rewriting

[StevenACoffman]

See issue #3321 - users of gqlgen who upgraded to v0.17.50 and had configured a layout of "single-file" for resolvers started to find their existing resolvers suddenly overwritten when re-generating models for schema changes. This change in behavior broke things for a number of people (sorry). It was intended that this behavior would be opt-in with a configuration option, but that was omitted.

This behavior change was introduced in #3243 to solve #3205 so that Bazel integration was possible (AFAICT Bazel needs a layout of "single-file" but needs to regenerate the resolver every time the schema updates). This was necessary for a big rewrite of the Apollo Federation code contributed by an organizations that use Bazel.

This PR adds a configuration option preserve_resolver that if explicitly set to true will not avoid rewriting the resolver when gqlgen is run.

This means that people who want the v0.17.49 single-file resolver behavior will need to add preserve_resolver: true to their gqlgen.yaml config.

I'm actively soliciting feedback as to whether it should be opt-out with preserve_resolver vs opt-in with rewrite_resolver.

What has always been awkward (and is of special concern in this PR) is that the gqlgen resolver rewrite/preserve behavior for a configured layout of follow-schema is the opposite of the old v0.17.49 single-file.

If we made the config option rewrite_resolver so that the default was false, then that implies that everyone who uses follow-schema layout needs to add rewrite_resolver: true or silently fail to update their resolvers.

I've already been very disruptive to one set of gqlgen users, I would prefer not to "fix it" by inflicting similar disruption to others, but I'm open to feedback or alternatives.

---

Note, I also fixed the annoying test regeneration cycle in a few tests so those tests begin by resetting to a good state before running.

Signed-off-by: Steve Coffman steve@khanacademy.org

[coveralls]

coverage: 59.422% (-0.02%) from 59.44%
when pulling 75966dc on single_file_rewrite_disable
into b207ed5 on master.

[StevenACoffman]

FYI @Vilsol @UnAfraid @JonasDoe

[JonasDoe]

Wow, thanks for the fast fix!

To answer your question: personally, the only reason why I'ld favor to default preserve_resolver to true is that it feels more like a guarantee this behavior isn't deprecated and will remain fully supported in the future. But from what I understand after reading your remarks, there's no reason to assume it might get dropped. So I'ld be fine with defaulting the setting to false, either. 🤷‍♂️

But if I understand correctly the big question you're asking is: how many ppl. have already updated their gqlgen since September, and how many haven't yet and might be startled by the changed behavior in the future? I'ld think most users don't update gqlgen avidly - you don't change your schemas that often, if even if you did, you wouldn't necessarily update this library each time. I might be wrong here, of course.

As a consolation: gqlgen still hasn't reached v1 (and I doubt it ever will), so technially you're free to break the api with every release. ;)

[argoyle]

I run Renovate on all my repositories to keep all dependencies up to date at all time (and recommend everyone else to do the same). Just to show the other side of the argument. 😁

[StevenACoffman]

We use gopkg.in/yaml.v3 to unmarshal/deserialize/decode from the yaml config to the resolver config struct so we cannot easily have gqlgen yaml configs that are missing any value for preserve_resolver default to true, as the zero value for a boolean is false.

There are 4,513 public repositories that import gqlgen and of the ones that appear actively maintained (commits in the last year) and use single-file layout, the majority have already updated to v0.17.50 or beyond.

I can't think of any way to get insight into private repository gqlgen version update information.

So it looks to me like if I flipped the single-file resolver rewrite back to the preserving behavior of v0.17.49 I would just make more trouble for most people who have already moved on.

BTW, there are 598 public repositories that have upgraded to v0.17.5x according to this: https://github.com/search?q=%22gh.neting.cc%2F99designs%2Fgqlgen+v0.17.5%22&type=code

Based on that and the feedback above, I'm going to try merging this PR as is, cut a release, and update the v0.17.50 release notes. Hopefully we can advertise this workaround to the break better for anyone who is late to updating.

Again, sorry for all the trouble. Thanks for remaining engaged and bringing it to my attention.

[StevenACoffman]

Fixes #3321 as best it can be fixed

[JonasDoe]

I run Renovate on all my repositories to keep all dependencies up to date at all time (and recommend everyone else to do the same). Just to show the other side of the argument. 😁

Yeah, the three of us who were posting in this issue probably belong to this other side. ;)

Regarding default values: I think I was just a bit sloppy on responding. It would have been rewrite_resolver: false instead of preserve_resolver: true then ofc.

This quey is interesting! But if you go the versions backwards here, it looks like only a minority of the public repos was actually updated.

Anyway, every solution is a good one, thank you again!