|
| 1 | +# GraphQL WG Notes - Feb 2025 |
| 2 | + |
| 3 | +**Watch the replays:** |
| 4 | +[GraphQL.js Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foHghwopNuQM7weyP5jR147I) |
| 5 | + |
| 6 | +- Intros, agreement, note taking volunteers and agenda review |
| 7 | +- Nullability RFC implementation (15m, Alex Reilly) |
| 8 | + - Alex: what are the action items that are left for nullability wg |
| 9 | + - @experimental_disableErrorPropagation change merged from Martin (https://github.com/graphql/graphql-js/pull/4348) |
| 10 | + - Document directive needs to be extracted into a separate PR. |
| 11 | + - Unsure of amount of work required for this. |
| 12 | + - Will delay until after general WG to see if this progresses and is needed. |
| 13 | + - Benjie: Talking about what can be experimented with once we release |
| 14 | + - Feature flags in the schema could be an option |
| 15 | + - Consider doing it w/o a concrete version number |
| 16 | + - Alex: Nullability WG meets later today, see what the group thinks |
| 17 | +- Releasing GraphQL v17 (10m, Jovi De Croock) |
| 18 | + - Jovi: Not intending to release now, but getting it stable |
| 19 | + - Export maps, let's get those in |
| 20 | + - ESM, ability to granularly export |
| 21 | + - process.env, get rid of it or default to production? |
| 22 | + - Opinions from client maintainers (e.g. Apollo) |
| 23 | + - Lenz is working through some options there, will follow up in the Issue |
| 24 | + - BigInt in scalars, can we skip it? |
| 25 | + - Not a breaking change, additive |
| 26 | + - Release beta or rc |
| 27 | + - API Documentation |
| 28 | + - [https://www.graphql-js.org/upgrade-guides/v16-v17/](https://www.graphql-js.org/upgrade-guides/v16-v17/) |
| 29 | + - Notes: |
| 30 | + - Benjie: there are RFC2 things coming down the line like the upcoming topic, and more things that we need to get in before v17, these have pull requests they need to get merged |
| 31 | + - Implementations may not deprecate fields that the interface did not deprecate |
| 32 | + - Operation types must exist |
| 33 | + - Tweak in default value coercion rules |
| 34 | + - Forbid skip and include in the subscription root |
| 35 | + - [https://github.com/graphql/graphql-spec/pull/793](https://github.com/graphql/graphql-spec/pull/793) is already merged into GraphQL.js, we should advance at spec WG to RFC3 |
| 36 | + - Benjie: where are we on ESM support |
| 37 | + - Let’s signal we’ll do it in v18 |
| 38 | +- Forbid @skip and @include directives in subscription root (10m, Benjie) |
| 39 | + - Benjie: catching up w/ latest |
| 40 | + - Side case in subscriptions where if you create a subscription document that uses skip/include in root selection set - you can use 3 fields, skip 2 and include the others, could be empty |
| 41 | + - Shouldn’t happen, at execution the wrong number of fields are surfaced and there’s an error |
| 42 | + - Wrote a small spec change to address - feedback from Lee was that it was a bit hacky |
| 43 | + - Validation doesn’t go into variable values - field collection does - in the spec I’ve pulled that algo out, updated it so that it speaks in terms of vars and explicitly disallows these directives |
| 44 | + - For graphqljs there’s a simpler approach - pass a forbidSkipAndInclude bool so we can do validation along these lines - git history shows it - created a new frozen null prototype obj |
| 45 | + - When checking, when var values is specifically this obj, forbid skip and include |
| 46 | + - Might rely too much on JavaScript-isms - porting may be too challenging |
| 47 | + - Feedback appreciated |
| 48 | + - RFC stage 2 in spec, won’t be rfc3 until merged in graphqljs |
| 49 | + - Jovi: I’ll try to make time for it in the next few days |
| 50 | + - Benjie: also on agenda in main WG |
| 51 | + - Yaacov: noticed after a quick look, collect fields algo returns a bit of error info |
| 52 | + - We have one other case where we have sort of an error that can be triggered by collect fields - subscription w/ defer for instance - I think we just throw an error there - want to double check. Maybe we could align both implementations |
| 53 | + - Benjie: you’re right - w/ field collection you generally don’t care - only matters from that one validation rule - we don’t want to throw, we want all the nodes collected then add them to the list of invalid parts of the doc - highlight each of those |
| 54 | + - In general, if this were to fail, it doesn’t actually matter acc to the execution algo, checks it in a different way |
| 55 | + - I have a slight concern over this - effectively when we call this we are creating an empty array when we call collect fields, which upsets me - was aiming for a clean diff |
| 56 | + - Yaacov: we don’t have to align, just a nice-to-have, will follow up if I have some other thoughts on this |
| 57 | + - Benjie: we could mirror the spec itself and duplicate the collection algo but it seems like, broadly, duplication of code w/o a massive payoff |
| 58 | + - Jovi: any other talking points? |
| 59 | + - Yaacov: reviewing agenda, you brought up good points |
| 60 | + - instanceof and how we plan on addressing that? Would it help to discuss here? |
| 61 | + - Jovi: Lenz from Apollo is working on a similar issue, working through options and will follow up |
0 commit comments