-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Preserve rewrite Config to Opt-out of breaking single-file resolver always rewriting #3359
Conversation
99f0354
to
1fff825
Compare
…riting Signed-off-by: Steve Coffman <[email protected]>
1fff825
to
75966dc
Compare
Wow, thanks for the fast fix! To answer your question: personally, the only reason why I'ld favor to default But if I understand correctly the big question you're asking is: how many ppl. have already updated their As a consolation: |
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. 😁 |
We use There are 4,513 public repositories that import gqlgen and of the ones that appear actively maintained (commits in the last year) and use 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=%22github.com%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. |
Fixes #3321 as best it can be fixed |
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 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! |
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
withpreserve_resolver
vsopt-in
withrewrite_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.49single-file
.If we made the config option
rewrite_resolver
so that the default was false, then that implies that everyone who usesfollow-schema
layout needs to addrewrite_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 [email protected]