New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service Workers #448

Closed
artemgurzhii opened this Issue May 30, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@artemgurzhii
Copy link

artemgurzhii commented May 30, 2017

Add service workers support.
There are 2 problems that I'm having now.
Service-worker should be served from the same origin as a website.
When adding service-worker.js into webpack entry points, and running ./bin/webpack-dev-server will produce this warning.
DOMException: Failed to register a ServiceWorker: The origin of the provided scriptURL ('http://0.0.0.0:8080') does not match the current origin ('http://localhost:3000')

Service workers have a scope which represents a URL that defines a service worker's registration scope, what range of URLs a service worker can control.
After the activation step, the service worker will control all pages that fall under its scope, so when registering worker from /packs/servise-worker.js and running ./bin/webpack-watcher it will control only localhost:300/packs/* pages.

@dhh

This comment has been minimized.

Copy link
Member

dhh commented Aug 8, 2017

I'm just starting to look into service workers and found the same issues. We already have a solution to the first problem: Use development: compile: true in webpacker.yml to lazy compile webpack from the development server and serve it there too. Then the URLs remain the same and that works. (Requires latest webpacker from github).

For the second issue, we need a different solution for the output directory. Really unfortunate that the service worker spec is so inflexible. Anyway, I'm thinking we might just make a specific configuration option for a root service worker. Feel free to open a PR attempting that!

@dhh dhh closed this Aug 8, 2017

@artemgurzhii

This comment has been minimized.

Copy link
Author

artemgurzhii commented Aug 8, 2017

@dhh Also, I forget to mention that there is a problem with caching rails assets pipeline generated files, as files cached by their name and my solution was to create serviceworker.js.erb file inside of which cache

 '<%= ActionController::Base.helpers.compute_asset_path("application.js") %>',
 '<%= ActionController::Base.helpers.compute_asset_path("application.css") %>'

files. Is there any way to give webpacker access on those file names so I can use them inside js file?

@dhh

This comment has been minimized.

Copy link
Member

dhh commented Aug 8, 2017

Yeah, we should come up with a complete solution for service workers and their configuration. I'm currently on a research trip into the land. Hopefully I'll come back with something. But agree that we should have some kind of bridge.

@gauravtiwari

This comment has been minimized.

Copy link
Collaborator

gauravtiwari commented Aug 9, 2017

@artemgurzhii The issue is fixed in latest master so service workers should now register fine. Have you tried it lately?

@dhh

This comment has been minimized.

Copy link
Member

dhh commented Aug 9, 2017

@gauravtiwari We still have the problem that service workers are being mounted under /packs rather than the root. Which means they don't really work. Need a way to get them mounted on the root. One idea is to simply compile to /packs, as per now, but then find a way to either symlink or just copy the file into the root as well.

@gauravtiwari

This comment has been minimized.

Copy link
Collaborator

gauravtiwari commented Aug 9, 2017

@dhh Ahh I see - giving this a try now. Are you using sw-precache plugin or custom implementation? https://github.com/goldhand/sw-precache-webpack-plugin

@dhh

This comment has been minimized.

Copy link
Member

dhh commented Aug 9, 2017

Not using any thing except a hand-rolled simple example at the moment. And I immediately hit the issue of service workers needing to be on the same origin and at the root.

@rossta

This comment has been minimized.

Copy link
Contributor

rossta commented Aug 9, 2017

As one point of reference, I'm using Webpack to bundle assets for my blog with a ServiceWorker without any special SW libraries or plugins: https://github.com/rossta/rossta.github.com/blob/develop/webpack.config.js

My example exports two separate Webpack configs, one for the site bundle and one for the serviceworker script. This allows me to target a different output for the serviceworker and decide which loaders and plugins to share or setup differently as needed.

For Webpacker, some considerations would be to omit the fingerprint from the filename so we can have a canonical URL and make it available at the root, e.g. /serviceworker.js. We'd also need to provide a host option separate from asset_host since the script must be available from the same domain (as opposed to a CDN).

Once registered, browsers are supposed to check for updated serviceworker script content regularly so devs would also want to avoid setting long term caching headers on the webservers for these scripts (not sure if browsers ignore caching headers for SW or not but it seems prudent to avoid setting them in the first place).

@hebergentilin

This comment has been minimized.

Copy link

hebergentilin commented Feb 23, 2018

@gauravtiwari how you add the sw.js at the root domain using the sw-precache-webpack-plugin?
This issue was fixed?

@jclif

This comment has been minimized.

Copy link

jclif commented Aug 15, 2018

Any update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment