node-graphql-server icon indicating copy to clipboard operation
node-graphql-server copied to clipboard

fix(deps): update dependency graphql-yoga to v5

Open renovate[bot] opened this issue 8 months ago • 0 comments

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
graphql-yoga (source) 1.18.3 -> 5.13.5 age adoption passing confidence

Release Notes

graphql-hive/graphql-yoga (graphql-yoga)

v5.13.5

Compare Source

Patch Changes

v5.13.4

Compare Source

Patch Changes

v5.13.3

Compare Source

Patch Changes

v5.13.2

Compare Source

Patch Changes

v5.13.1

Compare Source

Patch Changes

v5.13.0

Compare Source

Minor Changes
  • #​3793 63b78d5 Thanks @​EmrysMyrddin! - Add new Instrumentation API

    Introduction of a new API allowing to instrument the graphql pipeline.

    This new API differs from already existing Hooks by not having access to input/output of phases. The goal of Instrumentation is to run allow running code before, after or around the whole process of a phase, including plugins hooks executions.

    The main use case of this new API is observability (monitoring, tracing, etc...).

Basic usage
import { createYoga } from 'graphql-yoga'
import Sentry from '@​sentry/node'
import schema from './schema'

const server = createYoga({
  schema,
  plugins: [
    {
      instrumentation: {
        request: ({ request }, wrapped) =>
          Sentry.startSpan({ name: 'Graphql Operation' }, async () => {
            try {
              await wrapped()
            } catch (err) {
              Sentry.captureException(err)
            }
          })
      }
    }
  ]
})
Multiple instrumentation plugins

It is possible to have multiple instrumentation plugins (Prometheus and Sentry for example), they will be automatically composed by envelop in the same order than the plugin array (first is outermost, last is inner most).

import { createYoga } from 'graphql-yoga'
import schema from './schema'

const server = createYoga({
  schema,
  plugins: [useSentry(), useOpentelemetry()]
})
Custom instrumentation ordering

If the default composition ordering doesn't suite your need, you can manually compose instrumentation. This allows to have a different execution order of hooks and instrumentation.

import { composeInstrumentation, createYoga } from 'graphql-yoga'
import schema from './schema'

const { instrumentation: sentryInstrumentation, ...sentryPlugin } = useSentry()
const { instrumentation: otelInstrumentation, ...otelPlugin } = useOpentelemetry()
const instrumentation = composeInstrumentation([otelInstrumentation, sentryInstrumentation])

const server = createYoga({
  schema,
  plugins: [{ instrumentation }, useSentry(), useOpentelemetry()]
})
Patch Changes

v5.12.2

Compare Source

Patch Changes

v5.12.1

Patch Changes

v5.12.0

Minor Changes
Patch Changes

v5.11.0

Compare Source

Minor Changes
  • #​3727 5fd15b8 Thanks @​EmrysMyrddin! - Allow to configure the endpoint used by GraphiQL to send requests.

  • #​3736 d13b8a4 Thanks @​ardatan! - Now it is possible to replace or wrap the logic how GraphQLParams handled;

    By default Yoga calls Envelop to handle the parameters, but now you can replace it with your own logic.

    Example: Wrap the GraphQL handling pipeline in an AsyncLocalStorage

    function myPlugin(): Plugin {
      const context = new AsyncLocalStorage();
      return {
        onParams({ paramsHandler, setParamsHandler }) {
          const store = { foo: 'bar' }
          setParamsHandler(payload => context.run(store, paramsHandler, payload))
       }
    }
    

v5.10.11

Compare Source

Patch Changes

v5.10.10

Compare Source

Patch Changes

v5.10.9

Compare Source

Patch Changes

v5.10.8

Compare Source

Patch Changes
  • #​3588 ed344ea Thanks @​ardatan! - Mark createLRUCache utility as deprecated, and export it as _createLRUCache marking it as an internal utility

v5.10.7

Compare Source

Patch Changes

v5.10.6

Compare Source

Patch Changes

v5.10.5

Compare Source

Patch Changes

v5.10.4

Compare Source

Patch Changes

v5.10.3

Compare Source

Patch Changes

v5.10.2

Compare Source

Patch Changes
  • #​3491 7a413bc Thanks @​n1ru4l! - dependencies updates:

  • #​3491 7a413bc Thanks @​n1ru4l! - Fix issue where context values being shared between batched requests.

    A bug within @whatwg-node/server caused properties assigned to a batched requests context to be propagated to all other batched requests contexts. It is resolved by updating the dependency of @whatwg-node/server to 0.9.55.

v5.10.1

Compare Source

Patch Changes

v5.10.0

Compare Source

Minor Changes

v5.9.0

Compare Source

Minor Changes
Patch Changes

v5.8.0

Compare Source

Minor Changes
Patch Changes

v5.7.0

Compare Source

Minor Changes
  • #​3331 5dae4ab Thanks @​EmrysMyrddin! - Expose server context in onResultProcessHook. In particular, this gives access to the waitUntil method to cleanly handle hanging promises.

  • #​3331 5dae4ab Thanks @​EmrysMyrddin! - New hook: onExecutionResult which is triggered when an execution is done on the pipeline. If it is a batched operation, this is called per each operation in the batch

  • #​3331 5dae4ab Thanks @​EmrysMyrddin! - Expose the already existing waitUntil method from the server context.

Patch Changes

v5.6.3

Compare Source

Patch Changes

v5.6.2

Compare Source

Patch Changes

v5.6.1

Compare Source

Patch Changes

v5.6.0

Compare Source

Minor Changes
  • #​3333 9f3f945 Thanks @​ardatan! - By default, Yoga does not allow extra parameters in the request body other than query, operationName, extensions, and variables, then throws 400 HTTP Error. This change adds a new option called extraParamNames to allow extra parameters in the request body.

    import { createYoga } from 'graphql-yoga'
    
    const yoga = createYoga({
      /* other options */
      extraParamNames: ['extraParam1', 'extraParam2']
    })
    
    const res = await yoga.fetch('/graphql', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        query: 'query { __typename }',
        extraParam1: 'value1',
        extraParam2: 'value2'
      })
    })
    
    console.assert(res.status === 200)
    

v5.5.0

Compare Source

Minor Changes
  • #​3332 0208024 Thanks @​ardatan! - Customize the landing page by passing a custom renderer that returns Response to the landingPage option

    import { createYoga } from 'graphql-yoga'
    
    const yoga = createYoga({
      landingPage: ({ url, fetchAPI }) => {
        return new fetchAPI.Response(
          /* HTML */ `
            <!doctype html>
            <html>
              <head>
                <title>404 Not Found</title>
              </head>
              <body>
                <h1>404 Not Found</h1>
                <p>Sorry, the page (${url.pathname}) you are looking for could not be found.</p>
              </body>
            </html>
          `,
          {
            status: 404,
            headers: {
              'Content-Type': 'text/html'
            }
          }
        )
      }
    })
    

v5.4.0

Compare Source

Minor Changes
  • #​3314 d5dfe99 Thanks @​EmrysMyrddin! - Allow for full customization of the GraphiQL page.

    Props from the YogaGraphiQL are now forwarded to the underlying GraphiQL components.

    The graphiql option field type of the Yoga server as also been updated to document which options are configurable from the server side. Only serializable options are available.

  • #​3255 7335a82 Thanks @​nissy-dev! - support shouldPersistHeaders option in GraphiQL plugin

Patch Changes

v5.3.1

Compare Source

Patch Changes
  • #​3237 3324bbab Thanks @​ardatan! - dependencies updates:

  • #​3237 3324bbab Thanks @​ardatan! - In such environments like CloudFlare Workers, the request object in the context always has the initial request object, so it was impossible to access the actual Request object from the execution context. Now Yoga ensures that the request in the context is the same with the actual Request.

v5.3.0

Compare Source

Minor Changes
  • #​3197 f775b341 Thanks @​n1ru4l! - Experimental support for aborting GraphQL execution when the HTTP request is canceled.

    The execution of subsequent GraphQL resolvers is now aborted if the incoming HTTP request is canceled from the client side. This reduces the load of your API in case incoming requests with deep GraphQL operation selection sets are canceled.

    import { createYoga, useExecutionCancellation } from 'graphql-yoga'
    
    const yoga = createYoga({
      plugins: [useExecutionCancellation()]
    })
    

    Learn more in our docs

    Action Required In order to benefit from this new feature, you need to update your integration setup for Fastify, Koa and Hapi.

    - const response = await yoga.handleNodeRequest(req, { ... })
    + const response = await yoga.handleNodeRequestAndResponse(req, res, { ... })
    

    Please refer to the corresponding integration guides for examples.

Patch Changes

v5.2.0

Compare Source

Minor Changes
Patch Changes

v5.1.1

Compare Source

Patch Changes

v5.1.0

Compare Source

Minor Changes

v5.0.2

Compare Source

Patch Changes

v5.0.1

Compare Source

Patch Changes

v5.0.0

Compare Source

Major Changes
Patch Changes

v4.0.5

Compare Source

Patch Changes

v4.0.4

Compare Source

Patch Changes

v4.0.3

Compare Source

Patch Changes

v4.0.2

Compare Source

Patch Changes

v4.0.1

Compare Source

Patch Changes

v4.0.0

Compare Source

Major Changes
Patch Changes

v3.9.1

Compare Source

Patch Changes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

renovate[bot] avatar Apr 09 '25 12:04 renovate[bot]