Closed tmountjr closed 1 year ago
Example repo at https://github.com/tmountjr/edgio-vue3
Right, I had that set up in the repo with no apparent effect (but I just pushed my example to include them this time) - despite setting the filename to service-worker.js
and the source directory to src
(which all works fine when built), the plugin is still trying to load dev-sw.js
which doesn't exist and is causing a 404 when the site loads.
@tmountjr the library you're using is not compatible using classic
or module
, you've 2 options:
1) remove @edgio/prefetch
from your custom sw
2) use type: 'classic'
and use importScripts
also in your custom sw, you will also need to add rollup and esbuild polyfills in Vite configuration
"@esbuild-plugins/node-globals-polyfill": "^0.2.3"
and "process": "^0.11.10",
as dev dependenciesprocess
polyfills: import { NodeGlobalsPolyfillPlugin } from '@esbuild-plugins/node-globals-polyfill';
then add NodeGlobalsPolyfillPlugin({ process: true }),
to Vite plugins, and also add optimizeDeps.esbuildOptions
with this code:
optimizeDeps: {
esbuildOptions: {
define: {
global: 'globalThis'
},
plugins: [
NodeGlobalsPolyfillPlugin({ process: true }),
]
}
}
Adding process polyfills, I get this error:
Thanks for looking into it. We may have to skip using this plugin if the polyfill approach doesn't work out - dropping the framework's package isn't really an option.
Out of curiosity, what would make our library compatible with either classic
or module
?
Out of curiosity, what would make our library compatible with either
classic
ormodule
?
Provide 2 versions, one using importScripts
(current one) and another using ESM
like you're using in your custom SW.
I suggest you to remove only the imports from the custom sw not from the app.
@tmountjr if @edgio/prefetch
is your library, you can create one for Vite, you only need to replace process.env.EDGIO_**
with import.meta.env.VITE_EDGIO_**
using static imports (instead importScripts
).
You'll need to provide it with "type": "module"
adding exports
entry with dts
and js
module.
If you have public repo maybe I can take a look...
I don't know if the source is public or not - I imagine it isn't because we're probably doing something proprietary in there. But I'll check with the devX team - it turns out that our prefetching component (which is the primary use case for our service worker) has its own installation/registration method (I think it uses rollup on the backend to compile the SW and move it into the dist
folder), but there might be some benefits to tweaking things to work on a wider variety of setups, especially once you move past Vue and into other platforms.
In the meantime, I'll go ahead and close this since we have a working solution (updated the above repo and I'll keep it around for reference) and some leads on how to make it compatible here. Thanks for taking a look!
Is it possible to have a custom service worker running while in dev mode? My current setup uses a custom SW at
/sw/service-worker.js
, and a custom registration script at/src/registerServiceWorker.js
:My
vite.config.ts
looks like:(Should point out I'm using Vue, if it matters.)
In
/src/main.ts
I'm simply importing the SW registration file (import './registerServiceWorker.js'
) as Vue starts up.This all works great when I do a build and run that build - I can see my custom SW (which includes some code that's easily searchable even in the minified version, so I know the right service worker is being loaded). But when I am in dev mode via
yarn dev
the service worker is the defaultdev-sw.js
file. This makes it hard to develop my site with the SW functionality without having to stop and rebuild my project after every change. Is there a way to force the path of the dev service worker rather than use the one that the plugin builds?