Support for service-workers

[manoldonev]

trafficstars

Describe the bug

Mock Service Worker fails to initialize on startup (works on local VSCode):

Uncaught (in promise) Error: [MSW] Failed to register a Service Worker for scope ('https://visualization-assignment--5173.local.webcontainer.io/') with script ('https://visualization-assignment--5173.local.webcontainer.io/visualization-assignment/mockServiceWorker.js'): Service Worker script does not exist at the given path.

Did you forget to run "npx msw init <PUBLIC_DIR>"?

Learn more about creating the Service Worker script: https://mswjs.io/docs/cli/init
    at getWorkerInstance (msw.js?v=750958eb:21157:17)
    at async startWorkerInstance (msw.js?v=750958eb:22192:28)
    at async initializeMockServiceWorker (index.tsx:17:5)
    at async main (index.tsx:33:3)

Running the command npx msw init <PUBLIC_DIR> does not help. Generally the script location is resolved thru a call like ${import.meta.env.BASE_URL}mockServiceWorker.js so the problem might be there as well.

Link to the blitz that caused the error

https://stackblitz.com/~/github.com/manoldonev/visualization-assignment

Steps to reproduce

1. Execute pnpm start.
2. Error is logged in console -- screen remains blank

Expected behavior

App should load.

Parity with Local

• [X] I have run the project in my local machine and I could not reproduce the issue.

Screenshots

No response

Platform

Version = 1.67.0
Hash = c994f4b06d30d4ac09341f7888800531bc4a8e9c
WebContainer = 3e4f172269cb19a250be0dfdff1ab657cb850d0e

Browser name  = Chrome
Full version  = 106.0.0.0
Major version = 106
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
performance.memory = {
  "totalJSHeapSize": 168194126,
  "usedJSHeapSize": 157514542,
  "jsHeapSizeLimit": 4294705152
}

Additional context

No response

[jrvidal]

:wave: @manoldonev Unfortunately, WebContainer does not support registering a SW on the served page. It's true that the error is a bit confusing.

[samdenty]

This is tracked, and it's something we do want to support in the future - but it might be difficult

[markerikson]

I would realllly like to see this. I'm revamping the Redux tutorials and was considering switching our embeds to StackBlitz, but they rely on MSW to work and I just ran into this issue.

[henryz2004]

Bump, I also really need this feature. I keep getting really annoying CORS issues when I'm making requests inside of a WebContainer, so I set up a proxy to bypass that. Simplest way to redirect traffic through that proxy would be through a ServiceWorker, but I guess I can't do that now :(

[KurtGokhan]

For now, I am using setupServer from msw/native to get around this issue. It works well for my use case. It works because msw/native patches the global fetch and doesn't rely on service workers.

Pros:

• I can use the same MSW API and I don't have to write separate mocks for Stackblitz

Cons:

• It's not doing real requests so your requests don't show up in Devtools Network tab
• Some Vite config is required if you want to support both msw/browser and msw/native
• Not guaranteed to work in the future and for all use cases

[SamVerschueren]

@henryz2004 You can enable the CORS proxy on the StackBlitz side without setting up your own. Just create a .stackblitzrc file with the following content

{
  "corsProxy": true
}

See this example. Then try to run something like curl wttr.in which normally throws a CORS error.

Hope this resolves your issue.