@apollo/[email protected]

Patch Changes

• #7539 5d3c45be9 Thanks @mayakoneval! - 🐛 Bug Fix for Apollo Server Landing Pages on Safari. A Content Security Policy was added to our landing page html so that Safari can run the inline scripts we use to call the Embedded Sandbox & Explorer.

@apollo/[email protected]

Patch Changes

• Updated dependencies [5d3c45be9]:
  • @apollo/[email protected]

@apollo/[email protected]

Minor Changes

• #7504 22a5be934 Thanks @mayakoneval! - In the Apollo Server Landing Page Local config, you can now opt out of the telemetry that Apollo Studio runs in the
  embedded Sandbox & Explorer landing pages. This telemetry includes Google Analytics for event tracking and
  Sentry for error tracking.

  Example of the new config option:

  const server = new ApolloServer({
    typeDefs,
    resolvers,
    plugins: [
      process.env.NODE_ENV === 'production'
        ? ApolloServerPluginLandingPageProductionDefault({
            graphRef: 'my-graph-id@my-graph-variant',
            embed: {
              runTelemetry: false
            },
          })
        : ApolloServerPluginLandingPageLocalDefault({
            embed: {
              runTelemetry: false
            },
          }),
    ],
  });
  

@apollo/[email protected]

Patch Changes

• #7509 5c20aa02e Thanks @renovate! - Update graphql-http dependency

• #7475 b9ac2d6b2 Thanks @renovate! - Update graphql-http dependency

• Updated dependencies [22a5be934]:

  • @apollo/[email protected]

@apollo/[email protected]

Minor Changes

• #7465 1e808146a Thanks @trevor-scheer! - Introduce new opt-in configuration option to mitigate v4 status code regression

  Apollo Server v4 accidentally started responding to requests with an invalid variables object with a 200 status code, where v3 previously responded with a 400. In order to not break current behavior (potentially breaking users who have creatively worked around this issue) and offer a mitigation, we've added the following configuration option which we recommend for all users.

  new ApolloServer({
    // ...
    status400ForVariableCoercionErrors: true,
  });

  Specifically, this regression affects cases where input variable coercion fails. Variables of an incorrect type (i.e. String instead of Int) or unexpectedly null are examples that fail variable coercion. Additionally, missing or incorrect fields on input objects as well as custom scalars that throw during validation will also fail variable coercion. For more specifics on variable coercion, see the "Input Coercion" sections in the GraphQL spec.

  This will become the default behavior in Apollo Server v5 and the configuration option will be ignored / no longer needed.

Patch Changes

• #7454 f6e3ae021 Thanks @trevor-scheer! - Start building packages with TS 5.x, which should have no effect for users

• #7433 e0db95b96 Thanks @KGAdamCook! - Previously, when users provided their own documentStore, Apollo Server used a random prefix per schema in order to guarantee there was no shared state from one schema to the next. Now Apollo Server uses a hash of the schema, which enables the provided document store to be shared if you choose to do so.

@apollo/[email protected]

Patch Changes

• #7454 f6e3ae021 Thanks @trevor-scheer! - Start building packages with TS 5.x, which should have no effect for users

@apollo/[email protected]

Patch Changes

• #7454 f6e3ae021 Thanks @trevor-scheer! - Start building packages with TS 5.x, which should have no effect for users

• Updated dependencies [1e808146a, f6e3ae021, e0db95b96]:

  • @apollo/[email protected]

@apollo/[email protected]

Patch Changes

• #7439 4668f4594 Thanks @Igloczek! - Export types from response cache plugin

@apollo/[email protected]

Minor Changes

• #7431 7cc163ac8 Thanks @mayakoneval! - In the Apollo Server Landing Page Local config, you can now automatically turn off autopolling on your endpoints as well as pass headers used to introspect your schema, embed an operation from a collection, and configure whether the endpoint input box is editable. In the Apollo Server Landing Page Prod config, you can embed an operation from a collection & we fixed a bug introduced in release 4.4.0

  Example of all new config options:

  const server = new ApolloServer({
    typeDefs,
    resolvers,
    plugins: [
      process.env.NODE_ENV === 'production'
        ? ApolloServerPluginLandingPageProductionDefault({
            graphRef: 'my-graph-id@my-graph-variant',
            collectionId: 'abcdef',
            operationId: '12345'
            embed: true,
            footer: false,
          })
        : ApolloServerPluginLandingPageLocalDefault({
            collectionId: 'abcdef',
            operationId: '12345'
            embed: {
              initialState: {
                pollForSchemaUpdates: false,
                sharedHeaders: {
                  "HeaderNeededForIntrospection": "ValueForIntrospection"
                },
              },
              endpointIsEditable: true,
            },
            footer: false,
          }),
    ],
  });
  
  

• #7430 b694bb1dd Thanks @mayakoneval! - We now send your @apollo/server version to the embedded Explorer & Sandbox used in the landing pages for analytics.

Patch Changes

• #7432 8cbc61406 Thanks @mayakoneval! - Bug fix: TL;DR revert a previous change that stops passing includeCookies from the prod landing page config.

  Who was affected?

  Any Apollo Server instance that passes a graphRef to a production landing page with a non-default includeCookies value that does not match the Include cookies setting on your registered variant on studio.apollographql.com.

  How were they affected?

  From release 4.4.0 to this patch release, folks affected would have seen their Explorer requests being sent with cookies included only if they had set Include cookies on their variant. Cookies would not have been included by default.

@apollo/[email protected]

Patch Changes

• Updated dependencies [7cc163ac8, 8cbc61406, b694bb1dd]:
  • @apollo/[email protected]