[pull] main from graphql:main #127
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
return newPending alongside incremental results when completing a fragment = removes need to track `newPending` and `newIncrementalDataRecords` as part of the class = unifies handling of retrieving new pending for initial result, completed fragments, and stream items incremental entries
Use a stream that never resolves to better demonstrate how there will be a definite pending promise. Calling return on the underlying graph flushes the nextQueue anyway.
Reduces the number of times we need to check as to whether to flush the next queue.
-- we do not need a formal iterator as we are the only consumer.
Currently, when early execution is disabled, we still use the early execution logic to initiate execution groups, which may cause early initiation of non-pending execution groups. alternative to #4109, causes potentially stacking delays when combinations of shared and non-shared keys between sibling defers cause separate deferred grouped field sets for the same deferred fragment.
main improvement is to remove additional intermediate variables, i.e. `map`, `inOriginalResult`.
DeferredGroupedFieldSet => ExecutionGroup SubsequentResultRecord => DeliveryGroup ExecuteExecutionGroups => CollectExecutionGroups
currently not actively being used for code quality improvement — if found useful, can be restored
Currently it is possible to have unhandled promise rejections that arise from a mix of sync and async isTypeOf checks. This should fix that issue.
improves readability at the cost of pushing and then immediate popping
Previously, this was inlined into both executeOperation and collectAndExecuteSubfields, now it is a separate function. executeExecutionPlan calls "getNewDeferMap" instead of "addNewDeferredFragments" to also conform to the spec functional/immutable style. 
…4177) extracted from #3808 PR #3808 uses schema coordinates to improve GraphQL-JS error messages. To reduce the size of the PR, this commit standardizes error messages according to the general pattern that will be introduced with schema coordinates without introducing the coordinates themselves, in the hopes of aiding review of the later PR. EDITED 8/26/2024: I was able to reproduce all of the standardized error messages from #3808 except for the ones in getArgumentValues when it is passed a Field Definition, because the parent type is not passed. Everything else can be calculated for the error messages we are currently printing, although schema coordinates simplifies things. Extracting these changes out of #3808 and rebasing #3808 on main will therefore will better demonstrate how schema coordinates improves the clarity of some of our error messages (namely, getArgumentValues) and simplifies printing them.
This is a rebase of #3847 This implements execution of Fragment Arguments, and more specifically visiting, parsing and printing of fragment-spreads with arguments and fragment definitions with variables, as described by the spec changes in graphql/graphql-spec#1081. There are a few amendments in terms of execution and keying the fragment-spreads, these are reflected in mjmahone/graphql-spec#3 The purpose is to be able to independently review all the moving parts, the stacked PR's will contain mentions of open feedback that was present at the time. - [execution changes](JoviDeCroock#2) - [TypeInfo & validation changes](JoviDeCroock#4) - [validation changes in isolation](JoviDeCroock#5) CC @mjmahone the original author --------- Co-authored-by: mjmahone <[email protected]> Co-authored-by: Yaacov Rydzinski <[email protected]>
To simply suggest a larger cohort of reviewers for more complex changes, and add the caveat that merged changes may be reverted if consensus has not been reached at a GraphQL-JS WG meeting.
#4022) As surfaced in [Discord](https://discord.com/channels/625400653321076807/862957336082645006/1206980831915282532) this currently is a breaking change in the 16.x.x release line which is preventing folks from upgrading towards a security fix. This PR should result in a patch release on the 16 release line. This change was originally introduced to support CFW and browser environments which should still be supported with the `typeof` check CC @n1ru4l This also adds a check whether `.env` is present as in the DOM using `id="process"` defines that as a global which we don't want to access on accident. as shown in #4017 Bundles also target `process.env.NODE_ENV` specifically which fails when it replaces `globalThis.process.env.NODE_ENV` as this becomes `globalThis."production"` which is invalid syntax. Fixes #3978 Fixes #3918 Fixes #3928 Fixes #3758 Fixes #3934 This purposefully does not account for #3925 as we can't address this without breaking CF/plain browsers so the small byte-size increase will be expected for bundled browser environments. As a middle ground we did optimise the performance here. We can revisit this for v17. Most bundlers will be able to tree-shake this with a little help, in #4075 (comment) you can find a conclusion with a repo where we discuss a few. - Next.JS by default replaces [`process.env.NODE_ENV`](https://github.com/vercel/next.js/blob/b0ab0fe85fe8c93792051b058e060724ff373cc2/packages/next/webpack.config.js#L182) you can add `typeof process` linearly - Vite allows you to specify [`config.define`](https://vitejs.dev/config/shared-options.html#define) - ESBuild by default will replace `process.env.NODE_ENV` but does not support replacing `typeof process` - Rollup has a plugin for this https://www.npmjs.com/package/@rollup/plugin-replace Supersedes #4021 Supersedes #4019 Supersedes #3927 > This now also adds a documentation page on how to remove all of these
Co-authored-by: Saihajpreet Singh <[email protected]>
Errata: Left typescript at v5.4.x as deep dependency typedoc requires v5.4.x. Left eslint v8.x as not all plugins are compatible with v9. Code changes, in no particular order: 1. Prettier formatting changes. 2. Prettier moved to an async API, but the `writeGeneratedFile` utility, which previously included prettifying was passed as a callback function to TS and had to stay sync, so prettifying was separated into a separate async function -- the callback function luckily did not seem to actually requiring another round of prettifying, as it just involved renaming. All the other callsites of the new utility had to be made async. In the alternate, I investigated @prettier/sync and the lower-level make-synchronized and make-synchronous packages, but I could not get them working. 3. Plenty of eslint rule changes! I have tried to make sure that the rule list orders now match the linked documentation, so that further updates might be easier. 4. Minor docusaurus config tweaks to get the build to pass.
…QLEnumValue (#4288) this extracts logic from #3044 and #3145 (later rebased as #3807 and #3808) to implement more informative error messages without implementing [the full schema coordinate RFC](graphql/graphql-spec#794) This is a BREAKING CHANGE because these schema elements are now longer plain objects and function differently in various scenarios, for example with `String(<schemaElement>` `JSON.stringifu(<schemaElement>` and `.toString()` and `.toJSON()` --------- Co-authored-by: Jovi De Croock <[email protected]>
I was just trying to understand the new flows for how scalar values are represented/parsed/serialized, and noticed that the comments for a couple of these methods looked backwards. Really hoping I am not just confused about the terminology, and that these aren't actually correct 😅
New Spec PR: graphql/graphql-spec#1098 Old Spec PR: graphql/graphql-spec#947 Original issue raised by @benjaminjkraft : #3592
this way, if (when?) we re-enable incemental delivery support with subscriptions, the signature of collect fields will not need to change
#3814 added default value validation and coercion, deprecating `astFromValue()` (which was unsafe, used `serialize()` to uncoerce input values provided in the internal format) and replacing it with a call to `valueToLiteral()` which safely operates on external values. This PR makes that change backwards compatible by reintroducing it as a new config option of `default` instead of replacing the existing option of `defaultValue`, where the type of `default` is: ```ts export type GraphQLDefaultInput = | { value: unknown; literal?: never } | { literal: ConstValueNode; value?: never }; ``` `default.value` is the external default value, while old config option of `defaultValue` is the internal value. Instead of removing it in v17, it is deprecated, and will be removed in v18. Side note: `GraphqlDefaultInput` renamed from `GraphQlDefaultValueUsage` introduced within the #3814 PR stack. Co-authored-by: Michael Hayes <[email protected]>
…erred (#4320) In the "old" duplicating version of incremental delivery, `collectFields()` was responsible for branching, and it therefore allowed processing a deferred named fragment even if that named fragment had already been visited as a regular non-deferred named fragment. One could have argued against that, as the old version had the concept of inlining, and so we could have just skipped the named fragment and considered it inlined, but chose not to do that. Now that we have an algorithm without duplication of fields, revisiting a named fragment will have no effect, as within the `buildExecutionPlan()` step, all the duplicated fields will be removed. So we can just remove the exception and go back to the version pre-incremental delivery where we always skip a visited named fragment. Note that we still only consider a named fragment to have been visited if it was not marked as deferred, because in the case of overlapping deferred and non-deferred spreads of the same named fragment, we need to visit it as the non-deferred spread to actually realize that it is non-deferred. [As an aside, looks like I made a mistake in #3994 => we would never have wanted to ignore the result of `shouldIncludeNode()` => since we are removing all ignoring of these conditions with respect to defer, this PR "fixes" that mistake as well.]
Updated to reflect spec draft graphql/graphql-spec#1132 Also changed the argument order to match the spec draft
preserving content motivation: this clears the way to upgrade our eslint configuration to v9, which should hopefully let us update our custom rule configuration currently, when attempting to frontport the next js website from v16 to main, we get eslint errors surrounding our custom rules. if we re-implement our custom rules according to the latest eslint configuration, it should make it easier this change allows us to do that inter alia by removing the eslint typedoc plugin
This converts the existing website to nextra just like https://github.com/graphql/graphql.github.io. This is a first step in moving the documentation here and having a redirect from graphql.org to graphql-js.org. Not sure yet why codecov started failing 😅 when I run `testonly:cover` locally it tells me we are 100% covered. WDYT about isolating the dependencies for the website in that folder? As seen in 9c7d615 this prevents the weird CI leaks that we're seeing Resolves #4200 --------- Co-authored-by: Yaacov Rydzinski <[email protected]>
Checked for broken styles and fixed them and also went over the links by using linkinator. I did check a lot of tools but looks like there isn't a good way at the moment to check for broken links that is maintained. Resolves #4242
Ultimately I was trying this out to see whether we can tweak the docs easily, it made me realize that our docs are tailored to general GraphQL rather than how do we use this library. It made me come up with a few suggestions - We should have a toggle on code examples to switch between `buildSchema` and programatically creating the schema with i.e. `GraphQLObjectType` - Our documentation starts with a tutorial, this ultimately feels like a mistake, we should lead with an explanation of what GraphQL.JS is and what it aims to do, clearly outlining the goals of this project - We should line out use-cases for building on this library and best practices of how to go to production Resolves #2941 Resolves #2567
Not quite sure yet about contents of the overview page, also the header is pretty odd, feels like a nextra bug or I goofed the CSS up 😅 generally though it looks like the extra-button and search/... aren't in their own container preventing a good space-between. The absence of links seems to cause thsi.
This provides people with the option to choose between the template approach or the classes approach. This is a proposal to tackle #1368 [Preview](https://graphql-7w0ort26u-the-graph-ql-foundation.vercel.app/) This has been applied throughout the codebase now, however one of the things I am uncertain about is how we offer `buildSchema` with the GraphQLDefer/... directives? Should we add an option to `buildSchema`? The exports defined in that chapter seem to only exist in v17 so we should explicitly flag that.
Following typescript documentation, it's not possible override interface property, we can only add new props. Since it's declared as unknown dict, even if we merge `GraphQLErrorExtensions`, we can't access to our extensions without workaround and verbose typescript in source-code. It's annoying since apollo expose `GraphQLFormattedError` instead `GraphQLError` Refs: https://www.typescriptlang.org/docs/handbook/declaration-merging.html Refs: apollographql/apollo-client#11789
Currently input-unions and by extension the `@oneOf` directive aren't present in the documentation. I have opted to put this into the advanced section. The copy might be up for improvement, honestly fire away if there's more cases to cover, just wanted to get the ball rolling here. CC @benjie --------- Co-authored-by: Benjie <[email protected]>
CC @dimaMachina Is it possible for the sidebar on `api-v16` to restart? currently it inherits the root one
… same field (#4342) See discussion graphql/defer-stream-wg#100
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )