Generated service worker uses file paths under Windows 10

[jorispz]

Can you reproduce the problem with latest npm?

Yes, I upgraded to the npm version 4.6.1 and the proble is reproducible

Description

Under windows, in a brand new project created with create-react-app, the service worker uses the location on disk of the files to be cached in its cache configuration.

Expected behavior

The service worker uses the proper URLs for caching configuration

Environment

react-scripts@1.0.0
node v6.10.1
npm 4.6.1

Windows 10
Any browser (not a browser issue)

Reproducible Demo

Create a brand new app with create-react-app in the environment above, run npm run build, and check the contents of service-worker.js. It contains file paths, such as

var precacheConfig = [
  ["C:/dev/temp/pwatest/build/index.html", "df24d8c1abce89d06bc00d2023cdad0c"],
  [
    "C:/dev/temp/pwatest/build/static/css/main.9a0fe4f1.css",
    "3473922d6aed4c20bb69846d6027cacf"
  ],
  [
    "C:/dev/temp/pwatest/build/static/js/main.23e5d2a8.js",
    "d0f59b7dffbc3ff4835b038c8f3a4fdc"
  ],
  [
    "C:/dev/temp/pwatest/build/static/media/logo.5d5d9eef.svg",
    "5d5d9eefa31e5e13a6610d9fa7a283bb"
  ]
]

[gaearon]

Paging @jeffposnick for help.

[jeffposnick]

That's not good.

I just found goldhand/sw-precache-webpack-plugin#11 which indicates that this is a known problem with the Webpack wrapper to sw-precache. CC: @goldhand, the maintainer of that plugin about that.

I'm going to experiment and see if it's possible to pass in a safe, default stripPrefix configuration option that would accommodate the build setup without having to wait on a change to the underlying Webpack plugin.

[gaearon]

Given that many other tools are broken on Windows, we have historically made it a point to ensure that every Create React App feature is supported and works well on Windows. This issue is a high priority for us and any help or temporary workaround would be welcome (even a hacky one).

[jeffposnick]

Definitely understood. I'm actively investigating whether there's a clean workaround short of requiring a new version of sw-precache-webpack-plugin.

[goldhand]

@jeffposnick I've heard that setting stripPrefix: path.join(__dirname, 'dist').replace(/\\/g,"/") works for windows uses (as a temporary windows solution). I am looking into a fix that will work on windows without configuration.

[gaearon]

I have a Windows laptop so I can verify any fix if you explain how to check that it works.

[goldhand]

@gaearon In the generated service worker, the var precacheConfig should strip out the absolute paths from the webpack bundles and replace it with the webpack.publicPath setting. In the demo the absolute windows paths are still there and were never replaced.

[gaearon]

Do I understand correctly that I'd need to adjust that to be stripPrefix: path.join(__dirname, 'build').replace(/\\/g,"/")? Given that build is where we put the output.

[gaearon]

Or, rather, just path of my build folder (hierarchy is a bit different in this project).

[goldhand]

sorry, yes just the path to the build folder. I think path.join(__dirname, 'build') will point to the build folder but you're right, you just want to strip the path to the build folder (where ever that is).

[gaearon]

OK, I think #2255 helps in my testing. Thanks everybody for raising this and suggesting fixes.
Would be nice to have a more permanent fix for this upstream.

[goldhand]

@gaearon, I will be working on a permanent fix.

[jeffposnick]

Thanks so much for stepping in with that workaround, @goldhand!

As a heads-up, I've been trying to confirm that it works as intended for common c-r-a use cases, and I am seeing an issue where using that stripPrefix setting that was just merged will prevent the path of the custom homepage setting from package.json from being appended to the output URLs.

I am going to continue trying different scenarios, but I wanted to point out that this setting appears to be an issue for homepage users.

[jeffposnick]

{
  stripPrefix: (paths.appBuild + '/').replace(/\\/g, '/'),
}

is roughly equivalent, but with the additional property of stripping out the leading /, making all the URLs relative to the location of service-worker.js. Since the service worker will always be deployed at the correct sub-directory based on the homepage config, using relative paths should be a safe workaround.

[gaearon]

Ah, thanks for catching that.

[gaearon]

I assume just paths.appBuild.replace(/\\/g, '/') + '/' would work, right?

[jeffposnick]

That seems equivalent, yeah. Though I am not by a machine to test right now.

…

On May 19, 2017 11:40 AM, "Dan Abramov" ***@***.***> wrote: I just paths.appBuild.replace(/\\/g, '/') + '/' would work, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2235 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABqyLJoSLouC_HDCIZRm4VPoNvPMyNoZks5r7eIJgaJpZM4NgWkJ> .

[gaearon]

react-scripts@1.0.1 should be out with a fix.
Can you please verify it helps?

[jorispz]

Tested and I can confirm it works for me.

Thanks to all involved, this is an impressive turnaround time!

[goldhand]

Just published 0.9.2 on npm with the windows fix. It's here: goldhand/sw-precache-webpack-plugin#77
Will release that fix along with a fix for goldhand/sw-precache-webpack-plugin#74 in 0.11.1 if you would rather just wait for that to come out.