Description

I'm having multiple Bugsnag reports from Safari and Mobile Safari (various versions and browsers) of this error in .cache/production-app.js in publicLoader.loadPage:

Steps to reproduce

I don't see this Error in my macOS Safari. Website is https://lebikini.com

Expected result

No error

Actual result

An error

Environment

  System:
    OS: macOS 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.15.3 - ~/.nvm/versions/node/v10.15.3/bin/node
    Yarn: 1.19.0 - /usr/local/bin/yarn
    npm: 6.12.0 - ~/.nvm/versions/node/v10.15.3/bin/npm
  Languages:
    Python: 2.7.16 - /usr/local/bin/python
  Browsers:
    Chrome: 78.0.3904.97
    Firefox: 70.0
    Safari: 13.0.3
  npmPackages:
    gatsby: ^2.17.13 => 2.17.13
    gatsby-image: ^2.2.32 => 2.2.32
    gatsby-plugin-google-analytics: ^2.1.26 => 2.1.26
    gatsby-plugin-manifest: ^2.2.27 => 2.2.27
    gatsby-plugin-netlify: ^2.1.24 => 2.1.24
    gatsby-plugin-react-helmet: ^3.1.14 => 3.1.14
    gatsby-plugin-sharp: ^2.2.38 => 2.2.38
    gatsby-plugin-styled-components: ^3.1.12 => 3.1.12
    gatsby-plugin-typescript: ^2.1.17 => 2.1.17
    gatsby-source-filesystem: ^2.1.36 => 2.1.36
    gatsby-transformer-sharp: ^2.3.4 => 2.3.4

Related: https://github.com/gatsbyjs/gatsby/issues/15080

Description

gatsby develop hangs on source and transform nodes after querying a large WordPress installation (~9000 posts, ~35 pages).

Is there any guides as to what's too big for Gatsby to handle in this regards?

Environment

  System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 8.10.0 - ~/n/bin/node
    Yarn: 1.5.1 - ~/n/bin/yarn
    npm: 5.6.0 - ~/n/bin/npm
  Browsers:
    Chrome: 67.0.3396.99
    Safari: 11.1.2
  npmPackages:
    gatsby: ^1.9.273 => 1.9.273
    gatsby-image: ^1.0.54 => 1.0.54
    gatsby-link: ^1.6.45 => 1.6.45
    gatsby-plugin-google-analytics: ^1.0.27 => 1.0.31
    gatsby-plugin-postcss-sass: ^1.0.22 => 1.0.22
    gatsby-plugin-react-helmet: ^2.0.10 => 2.0.11
    gatsby-plugin-react-next: ^1.0.11 => 1.0.11
    gatsby-plugin-resolve-src: 1.1.3 => 1.1.3
    gatsby-plugin-sharp: ^1.6.48 => 1.6.48
    gatsby-plugin-svgr: ^1.0.1 => 1.0.1
    gatsby-source-filesystem: ^1.5.39 => 1.5.39
    gatsby-source-wordpress: ^2.0.93 => 2.0.93
    gatsby-transformer-sharp: ^1.6.27 => 1.6.27
  npmGlobalPackages:
    gatsby-cli: 1.1.58

edit: Just want to reiterate—this is not something easily fixable by deleted .cache/, .node_modules, etc. If that resolves your problem, you weren't experiencing this issue.

This is a meta issue for all the issues with 2.2.0, that were introduced by the schema refactoring.

What?

See the blog post for the details about why we did the refactoring and what's it all about.

See the release blog post for release notes and final updates.

How?

Install latest version of Gatsby and try running your site. Hopefully it will all just work. If you want, you could also try the two new APIs (createTypes and createResolvers).

yarn add gatsby

Changelog

[email protected]

• Published

[email protected]

• Moved to explicit directives instead of addResolver

[email protected]

• Master back merge, upgrade graphql-compose

[email protected]

• See #13028

[email protected]

• :champagne:

[email protected]

• Fixed a regression when empty strings mixed with dates cause stuff to not be intrepreted as dates

[email protected]

• merge latest master
• docs update

[email protected]

• merge latest master
• better SDL parse error messages

[email protected]

• fix regression in connection naming in case types are lowercase named

[email protected]

• Fixed custom scalars not having any filters
• Added errors when trying to override Node interface or generated filter/sort types.

[email protected]

• Added a new convenience API modelled after graphql-compose. See using-type-definitions example.

exports.sourceNodes = ({ actions, schema }) => {
  const { createTypes } = actions
  createTypes([
    schema.buildObjectType({
      name: `CommentJson`,
      fields: {
        text: `String!`,
        blog: {
          type: `BlogJson`,
          resolve(parent, args, context) {
            return context.nodeModel.getNodeById({
              id: parent.author,
              type: `BlogJson`,
            })
          },
        },
        author: {
          type: `AuthorJson`,
          resolve(parent, args, context) {
            return context.nodeModel.getNodeById({
              id: parent.author,
              type: `AuthorJson`,
            })
          },
        },
      },
      interfaces: [`Node`],
    }),
  ])
}

[email protected]

• Fixed regression with Node id field not being a String, like in current master.
• Upgraded to [email protected]
• FilterInput types are now not prefixed by output type, reducing proliferation of types

[email protected]

• Fixed issue with pagination over null query results
• @dontInfer(noDefaultResolvers: false) actually works
• in createResolvers resolvers info.originalResolver is available even if there is no resolver on original field

[email protected]

• Redone alpha version with proper release version
• Fix Node types without actual nodes not being added

[email protected]

• Initial alpha

Gatsby is awesome!

Has been a while that I'm familiar with the project and I think it needs an equivalent awesome logo. Today I've seen this on Hacker News and I think it could be a nice spark for this discussion.

@KyleAMathews do you have any ideas in mind?

Just wondering whether there is some information that could be of use here, since I've found in my sites a significant worsening of lighthouse results when comparing lighthouse v5.6 vs the new 6.0 (https://lighthouse-metrics.com/)

In a complex site (of mine) it goes (performance-wise) from a ~90 to ~50 In a simple starter (of mine) it lowers from ~98 to ~80

This doesn't happen in starters such as https://gatsby-starter-default-demo.netlify.app/ or https://gatsby-v2-perf.netlify.app/

But it does happen to www.gatsbyjs.org (from ~98 to ~73) or to https://theme-ui.com (from ~90 to ~75)

Since I spent some time achieving 98-100 punctuations in my code (which made me very happy), I kind of feel I don't have a lot of room for improvement (probably I do have), so I've thought I might ask here if there's something going on

Thanks

Description

When I use gatsby-plugin-react-helmet I notice that the <Helmet /> components come way too late in the head tag. I have noticed that on occasion for instance Facebook does not always parse the og tags if they come too late in the head.

Steps to reproduce

Just use <Helmet />, and notice in the static output files there is a lot of CSS related stuff etc. above the helmet tag in the <head>.

Expected result

Helmet tags should be prioritised when doing the <head /> tag.

Workaround

Currently there is easy workaround, but I consider that gatsby's default is broken. We should not need workaround for this.

gatsby-ssr.js

var React = require("react");

// Hack, to reorder the helmet components as first in <head> tag
exports.onPreRenderHTML = ({ getHeadComponents, replaceHeadComponents }) => {
    /**
     * @type {any[]} headComponents
     */
    const headComponents = getHeadComponents();

    headComponents.sort((a, b) => {
        if (a.props && a.props["data-react-helmet"]) {
            return 0;
        }
        return 1;
    });
    replaceHeadComponents(headComponents);
};

Changes made:

• <div> is replaced with <span> in gatsby-plugin-offline's app-shell.js to prevent an edge case in Chrome, where the the outer element's class attribute is unset despite its className being set in the VDOM, if the page was loaded from the offline shell.
• A call to getResourcesForPathname was fixed - previously this prevented later code from calling since Promise.all(pathnameResources) would never resolve.
• Styles are now searched as well as scripts when caching resources, and these are all cached regardless of whether they are included in pageResources.
• Styles are also now searched in get-resources-from-html.js.
• The offline shell and custom 404 page are now also scanned for resources when considering critical file paths.
  • get-resources-from-html.js is modified so that if a custom 404 page doesn't exist, an empty array will be returned.
• A glob for Webpack chunks is added to the precache options, as these are sometimes loaded from other chunks and therefore not detected by getResourcesFromHTML, causing errors to occur when trying to navigate to another page when offline (if they haven't all been cached).
• The navigateFallbackWhitelist regex is modified to prevent loading the offline shell if the URL ends with ?no-cache=1 or &no-cache=1.
• sw.js is patched to include search queries when matching URLs against navigateFallbackWhitelist. Unfortunately I couldn't find any options to enable this, so patching appears to be the only way until a change is made upstream.
  • An error is thrown asking the user to report an issue if the patch fails - this will cause the build to fail, but will avoid confusion in the long run if the patch stops working.
  • I checked the ignoreUrlParametersMatching options, but it's for ignoring differences, e.g. between /page/ and /page/?utm_source=github, not for disabling caching or fallback.
• JSON and CSS resources are cached at runtime.
• page-renderer.js now checks for this.state.pageResources.json, since errors were previously occurring even when this.state.pageResources existed due to the missing JSON data.
• When a page isn't found, an attempt is made to load it directly, in order to display a proper error message, i.e. 404 or offline error, or simply load it directly if it's available online (e.g. /admin/ for CMS, which is not directly part of Gatsby).
• A clause has been added to an if statement in production-app.js to prevent the 404 showing until an attempt has been made to load the page directly
  • #7268 had actually broken support for static pages (e.g. Netlify CMS at /admin/) since the service worker would be unable to find the page from Gatsby and show a 404
• onServiceWorkerInstalled is now delayed by 100ms, since it was being called before the fetch event listeners were added, thus preventing resources from being cached. Unfortunately I couldn't find a programmatic way to do this (other than more patching of sw.js, which is less than ideal).
  • It might be worth increasing this to 500ms, since at 100ms it could still fail for more complex sites (despite working at as low as 20ms in local testing). Thoughts?
• checkIfDoingInitialRenderForSW is removed from loader.js as it was causing the SW to be removed when navigating to a nonexistent page, even if the website had not been updated, causing it to stop working offline entirely - regardless, it is no longer needed with the other changes made.
• README for gatsby-plugin-offline is updated to match the latest default options.

Closes #6212, Closes #7053, Closes #6688, possibly others

Summary

Periodically on my production site I'm seeing the following error;

Error: Missing resources for /
  at render(./.cache/ensure-resources.js:133:17)
  at Sg(./node_modules/react-dom/cjs/react-dom.production.min.js:169:129)
  at Hh(./node_modules/react-dom/cjs/react-dom.production.min.js:214:16)
  at Ih(./node_modules/react-dom/cjs/react-dom.production.min.js:215:274)
  at ji(./node_modules/react-dom/cjs/react-dom.production.min.js:230:233)
  at ki(./node_modules/react-dom/cjs/react-dom.production.min.js:229:143)
  at Fh(./node_modules/react-dom/cjs/react-dom.production.min.js:226:196)
  at bg(./node_modules/react-dom/cjs/react-dom.production.min.js:224:28)
  at qi(./node_modules/react-dom/cjs/react-dom.production.min.js:243:14)
  at render(./node_modules/react-dom/cjs/react-dom.production.min.js:251:109)
  at oi(./node_modules/react-dom/cjs/react-dom.production.min.js:254:364)
  at Ai(./node_modules/react-dom/cjs/react-dom.production.min.js:254:350)
  at apply(./.cache/production-app.js:114:7)
  at r(./node_modules/@sentry/browser/dist/index.js:3114:1)

It seems like sometimes this causes the site to not render at all and just show a blank page.

Relevant information

You can see the trace on Sentry here

Environment (if relevant)

This is the env on which the site is built;

  System:
    OS: macOS High Sierra 10.13.2
    CPU: x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 8.11.1 - ~/.nvm/versions/node/v8.11.1/bin/node
    Yarn: 1.9.4 - ~/.nvm/versions/node/v8.11.1/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v8.11.1/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Safari: 11.0.2
  npmPackages:
    gatsby: ^2.0.19 => 2.0.72
    gatsby-image: ^2.0.15 => 2.0.20
    gatsby-plugin-create-client-paths: ^2.0.2 => 2.0.2
    gatsby-plugin-google-gtag: ^1.0.8 => 1.0.8
    gatsby-plugin-manifest: ^2.0.5 => 2.0.10
    gatsby-plugin-offline: ^2.0.11 => 2.0.17
    gatsby-plugin-page-transitions: ^1.0.7 => 1.0.7
    gatsby-plugin-react-helmet: ^3.0.0 => 3.0.2
    gatsby-plugin-sharp: ^2.0.18 => 2.0.18
    gatsby-plugin-stripe-elements: ^1.0.9 => 1.0.9
    gatsby-plugin-twitter: ^2.0.8 => 2.0.8
    gatsby-source-filesystem: ^2.0.4 => 2.0.12
    gatsby-transformer-sharp: ^2.1.12 => 2.1.12
  npmGlobalPackages:
    gatsby-cli: 2.0.0-rc.1
    gatsby-plugin-countly: 0.2.0

No idea where to start with debugging this so any help is appreciated!

Preliminary Checks

• [X] This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• [X] This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

When trying to run Gatsby latest 4.9.1 I get this error

4:35:23 PM: success write out requires - 0.005s
4:36:27 PM: success Building production JavaScript and CSS bundles - 63.377s
4:37:03 PM: success Building HTML renderer - 36.060s
4:37:03 PM: success Execute page configs - 0.380s
4:37:03 PM: success Caching Webpack compilations - 0.001s
4:37:03 PM: error (node:2227) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 end listeners added to [PassThrough]. Use emitter.setMaxListeners() to increase limit
4:37:03 PM: (Use `node --trace-warnings ...` to show where the warning was created)
4:37:07 PM: success run queries in workers - 3.599s - 37/37 10.28/s
4:37:09 PM: success Running gatsby-plugin-sharp.IMAGE_PROCESSING jobs - 120.528s - 5/5 0.04/s
4:37:09 PM: error UNHANDLED EXCEPTION write EPIPE
4:37:09 PM: 
4:37:09 PM: 
4:37:09 PM:   Error: write EPIPE
4:37:09 PM:   
4:37:09 PM:   - child_process:864 ChildProcess.target._send
4:37:09 PM:     node:internal/child_process:864:20
4:37:09 PM:   
4:37:09 PM:   - child_process:737 ChildProcess.target.send
4:37:09 PM:     node:internal/child_process:737:19
4:37:09 PM:   
4:37:09 PM:   - index.js:291 WorkerPool.sendMessage
4:37:09 PM:     [repo]/[gatsby-worker]/dist/index.js:291:19
4:37:09 PM:   
4:37:09 PM:   - worker-messaging.ts:22 
4:37:09 PM:     [repo]/[gatsby]/src/utils/jobs/worker-messaging.ts:22:22
4:37:09 PM:   
4:37:09 PM: 
4:37:09 PM: not finished Merge worker state - 0.058s
4:37:09 PM: error Command failed with exit code 1.
4:37:09 PM: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
4:37:09 PM: ​
4:37:09 PM: ────────────────────────────────────────────────────────────────
4:37:09 PM:   "build.command" failed                                        
4:37:09 PM: ────────────────────────────────────────────────────────────────
4:37:09 PM: ​
4:37:09 PM:   Error message
4:37:09 PM:   Command failed with exit code 1: yarn postinstall && yarn build:incremental
4:37:09 PM: ​
4:37:09 PM:   Error location
4:37:09 PM:   In build.command from netlify.toml:
4:37:09 PM:   yarn postinstall && yarn build:incremental
4:37:09 PM:

I cleared my Netlify cache before running this and this seems like a new issue as per https://github.com/gatsbyjs/gatsby/issues/33738#issuecomment-1055595579

Reproduction Link

tbd

Steps to Reproduce

Following steps outlined here: https://github.com/gatsbyjs/gatsby/issues/33738

Expected Result

For the site to build as it normally did before I updated packages.

Actual Result

Consistently fails

Environment

System:
    OS: macOS 12.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 17.4.0 - /var/folders/tb/qb7x5sw53vngt06y9g92csn80000gp/T/yarn--1646432031346-0.9788514151471666/node
    Yarn: 1.22.17 - /var/folders/tb/qb7x5sw53vngt06y9g92csn80000gp/T/yarn--1646432031346-0.9788514151471666/yarn
    npm: 8.3.1 - ~/.nvm/versions/node/v17.4.0/bin/npm
  Languages:
    Python: 2.7.18 - /usr/bin/python
  Browsers:
    Chrome: 99.0.4844.51
    Safari: 15.1

Config Flags

GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true

Links/References

https://answers.netlify.com/t/error-unhandled-exception-write-epipe/52650 https://answers.netlify.com/t/gatsby-v4-works-locally-but-timed-out-on-netlify/46339/2 https://answers.netlify.com/t/gatsby-v4-works-locally-but-timed-out-on-netlify/46339/21

Description

I'm processing around 1500 images with gatsby-plugin-sharp/gatsby-transformer-sharp and GraphQL, to display with gatsby-image as per this page in the docs.

For smaller numbers of images I have had no issues, but now that I'm processing 1500 images the build randomly fails with the following error:

(sharp:104): GLib-GObject-WARNING **: 09:35:11.293: gtype.c:4265: type id '0' is invalid

(sharp:104): GLib-GObject-WARNING **: 09:35:11.293: can't peek value table for type '<invalid>' which is not currently referenced

(sharp:104): GLib-GObject-WARNING **: 09:35:11.293: gvalue.c:188: cannot initialize GValue with type '(null)', this type has no GTypeValueTable implementation

(sharp:104): GLib-GObject-CRITICAL **: 09:35:11.293: g_value_transform: assertion 'G_IS_VALUE (src_value)' failed
Received 'segmentation fault' signal

This happens during the "Generating image thumbnails" step in the build process and it occurs apparently randomly (sometimes 10% of the way through the images, sometimes at 80%, sometimes not at all). Therefore I do not believe it is caused by a "faulty image".

Who wants to design a Gatsby t-shirt!?!

We have $1240 available on OpenCollective that seems like it needs turned into t-shirts :-)

But to do that we need a design. So please submit some designs! If you submit the design that gets picked, I'll send you 3 t-shirts.

I'm also going to send t-shirts to all the 1.0 contributors.

What's the best t-shirt printing place these days? Ideally they'd be a print on-demand place so people could buy Gatsby shirts for themselves.

Description

Add existing limitation to docs.

Documentation

https://www.gatsbyjs.com/docs/reference/built-in-components/gatsby-script/#limitations

Related Issues

Resolves https://github.com/gatsbyjs/gatsby/issues/37024

Description

Bump yaml-loader so it uses loader-utils 2 or greater changed in https://github.com/eemeli/yaml-loader/commit/d9f769feb229c5da2d680614b380083ff073c24a.

Documentation

N/A

Related Issues

N/A

Description

This PR fixes a bug with gatsby-source-shopify. Specifically, passing the placeholder: 'BLURRED' option to a ShopifyMediaImage GraphQL query doesn't work - gatsby source shopify returns an error, "TypeError: Cannot read properties of undefined (reading 'contentDigest')".

The change is simple, switch out the 'contentDigest' parameter for an 'imageId' parameter. Content digest was 'image.internal.contentDigest' - imageId is 'image.id'. This parameter is a unique string used as a cacheKey for the image.

Documentation

The gatsby source shopify docs don't go into this. It's a tiny change.

Related Issues

Fixes #35930

Preliminary Checks

• [X] This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• [X] This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

Whenever building my website Gatsby crashes on the image processing part.

Start processing D:\repos\website\public\static\c4dab60483da3cbd37e20af2780ad243\b105a\IMG_0506-1200x800.webp
warn Your GraphQL query in createPages took 21.278 seconds which is an unexpectedly long time. See https://gatsby.dev/create-pages-performance for tips on how to improve this.
⠴ createPages
[======================      ]   21.144 s 98/121 81% Running gatsby-plugin-sharp.IMAGE_PROCESSING jobs
PS D:\repos\twill-net\website> ^F

Tried following:

• Clearing Gatsby cache
• Using different node version
• Updating to latest Gatsby version
• Lowering parallel CPU count
• Tried logging inside the gatsby-plugin library to see or this is related to specific images

It started occuring at some point. Can't really share more as it is a large website where images are added on a regular frequency. Problem seems to be only occuring on Windows.

When running gatsby build again, it can go an image further. It looks to me that it puts a limit on how long it can process images or page queries?

It just stops processing and doesn't report an error, so might be some timeout or something? Any setting I can override?

Thanks!!

Reproduction Link

/

Steps to Reproduce

/

Expected Result

Processing is done just fine

Actual Result

Image processing exits without warning

Environment

System:
    OS: Windows 10 10.0.22621
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i7-12700K
  Binaries:
    Node: 19.2.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
    npm: 8.19.3 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 3.10.2
  Browsers:
    Edge: Spartan (44.22621.963.0), Chromium (108.0.1462.54)
  npmGlobalPackages:
    gatsby-cli: 5.3.1

Config Flags

SSR / DSG: Disabled

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | @babel/cli (source) | ^7.15.4 -> ^7.20.7 | | | | | | @babel/code-frame (source) | ^7.14.0 -> ^7.18.6 | | | | | | @babel/core (source) | ^7.15.5 -> ^7.20.7 | | | | | | @babel/eslint-parser (source) | ^7.15.4 -> ^7.19.1 | | | | | | @babel/generator (source) | ^7.16.8 -> ^7.20.7 | | | | | | @babel/helper-plugin-test-runner (source) | 7.14.5 -> 7.18.6 | | | | | | @babel/helper-plugin-utils (source) | ^7.14.5 -> ^7.20.2 | | | | | | @babel/node (source) | ^7.15.4 -> ^7.20.7 | | | | | | @babel/parser (source) | ^7.15.5 -> ^7.20.7 | | | | | | @babel/plugin-proposal-class-properties (source) | ^7.14.0 -> ^7.18.6 | | | | | | @babel/plugin-proposal-nullish-coalescing-operator (source) | ^7.14.5 -> ^7.18.6 | | | | | | @babel/plugin-proposal-numeric-separator (source) | ^7.14.5 -> ^7.18.6 | | | | | | @babel/plugin-proposal-optional-chaining (source) | ^7.14.5 -> ^7.20.7 | | | | | | @babel/plugin-proposal-private-methods (source) | ^7.14.0 -> ^7.18.6 | | | | | | @babel/plugin-syntax-jsx (source) | ^7.14.0 -> ^7.18.6 | | | | | | @babel/plugin-syntax-typescript (source) | ^7.14.0 -> ^7.20.0 | | | | | | @babel/plugin-transform-classes (source) | ^7.15.4 -> ^7.20.7 | | | | | | @babel/plugin-transform-modules-commonjs (source) | ^7.15.4 -> ^7.20.11 | | | | | | @babel/plugin-transform-runtime (source) | ^7.15.0 -> ^7.19.6 | | | | | | @babel/plugin-transform-spread (source) | ^7.14.6 -> ^7.20.7 | | | | | | @babel/plugin-transform-typescript (source) | ^7.15.4 -> ^7.20.7 | | | | | | @babel/preset-env (source) | ^7.15.4 -> ^7.20.2 | | | | | | @babel/preset-flow (source) | ^7.14.0 -> ^7.18.6 | | | | | | @babel/preset-react (source) | ^7.14.0 -> ^7.18.6 | | | | | | @babel/preset-typescript (source) | ^7.15.0 -> ^7.18.6 | | | | | | @babel/register (source) | ^7.15.3 -> ^7.18.9 | | | | | | @babel/runtime (source) | ^7.15.4 -> ^7.20.7 | | | | | | @babel/template (source) | ^7.16.7 -> ^7.20.7 | | | | | | @babel/traverse (source) | ^7.15.4 -> ^7.20.10 | | | | | | @babel/types (source) | ^7.15.4 -> ^7.20.7 | | | | |

Release Notes

Configuration

📅 Schedule: Branch creation - "before 7am on the first day of the month" in timezone GMT, 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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

This PR has been generated by Mend Renovate. View repository job log here.

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | msw (source) | ^0.38.2 -> ^0.49.2 | | | | | | node-fetch | ^2.6.6 -> ^2.6.7 | | | | |

Release Notes

server.listHandlers()
worker.listHandlers()

rest.post('/user', async (req, res, ctx) => {
  const newUser = await req.json()
})

rest.get('/resource', (req, res, ctx) => {
// I want to perform this intercepted request as-is.
-  return
+  return req.passthrough()
})

Configuration

📅 Schedule: Branch creation - "before 7am on the first day of the month" in timezone GMT, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

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

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

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

This PR has been generated by Mend Renovate. View repository job log here.