Gatsby Script Api: partytown service worker only register in the index page

[twodft]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• 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

Using the Gatsby Script API's off-main-thread strategy to implement Google Analytics on my website, and found the partytown service worker partytown-sw.js only registers through the index page endpoint, which means Google Analytics script will only work when the user visits my site start from the homepage.

Note: I have double-checked that this is not a bug from upstream Partytown

Reproduction Link

https://github.com/twodft/gatsby-script-component-google-analytics-issue

Steps to Reproduce

1. Visit https://gatsbyscriptcomponentgoog91859.gatsbyjs.io/ you will find the partytown service worker success registered, and Google Analytics started to work.
2. In another incognito tab, visit https://gatsbyscriptcomponentgoog91859.gatsbyjs.io/second/ the service worker did not register, and Google Analytics won't work on this page
3. Also, I had implemented Google gtag directly with Partytown in this pr, and got this preview link, https://gatsbyscriptcomponentgoog91859-usepartytown.gtsb.io/ You can find the partytown service worker success registered on any page and this make Google Analytics tags work properly
   ...

Expected Result

When using Gatsby Script's off-main-thread strategy, the partytown service worker should be able to register on any page, not only just from the index page.

Actual Result

partytown service worker would not register on other pages except the index page

Environment

  System:
    OS: Windows 10 10.0.22621
    CPU: (12) x64 Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz
  Binaries:
    Node: 18.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 3.10.5 - /c/Users/Administrator/AppData/Local/Programs/Python/Python310/python
  Browsers:
    Edge: Spartan (44.22621.819.0), Chromium (107.0.1418.42)
  npmPackages:
    gatsby: ^4.21.1 => 4.21.1 
  npmGlobalPackages:
    gatsby-cli: 5.0.0

Config Flags

No response

[Rbcoder1]

Give me chance to solve this issue.
am interested to solve this issue

[ShaunDychko]

It shouldn't make a difference, but I have a similar setup working properly on https://www.giancolianswers.com that adds the script using wrapPageElement instead of wrapRootElement in both gatsby-browser.js and gatsby-ssr.js. Maybe that's worth a try?

[ShaunDychko]

The next shot-in-the-dark would be to try with React 17 and React-Dom 17.

[tyhopp]

Hi @twodft, I was able to reproduce this when using the off-main-thread strategy with the wrapRootElement API. The wrapPageElement API works as expected as @ShaunDychko mentioned.

For now I've opened #37402 to document this limitation. A fix is something that is probably possible but I can't prioritize at the moment. At the very least there is a workaround available via the wrapPageElement API.

Some breadcrumbs if anyone (or my future self) is interested in picking this up:

• Gatsby Script depends on useLocation from @gatsbyjs/reach-router to collect scripts in

  gatsby/packages/gatsby-script/src/gatsby-script.tsx

  Lines 98 to 100 in bbd6220

  	if (typeof window === `undefined`) {
  	collectedScriptsByPage.set(pathname, attributes)
  	}

  and Gatsby expects those collected scripts to exist during server-side rendering
• The location props available at this point when an off-main-thread script is used in wrapRootElement is incorrect, and Gatsby is not able to differentiate that the scripts are used in different pages, instead thinking the script is used only on the index page
• This likely has something to do with how we wrap location providers in static-entry, so for a fix I'd look there first