Sapper legacy mode: CSS not loaded on route change

[rodoch]

Describe the bug
This issue occurs when using a production build (npm run build) of Sapper created with the --legacy flag in a browser which relies on the legacy code (i.e. a browser with no native support for async/await syntax).

When navigating from Page A to page B the CSS associated with the page B route is not loaded and the contents of page B remain unstyled. This does not affect the styling of any components already loaded on page A.

Logs
When testing this in Chrome 54 the console displays the following errors:

service-worker.js:1 Uncaught SyntaxError: missing ) after argument list 
(index):1 Uncaught (in promise) TypeError: Failed to register ServiceWorker: ServiceWorker script evaluation failed

However, this appears to be unrelated to the problem. Removing the service worker from the project and rebuilding does not alleviate the issue.

To Reproduce
I've created a minimal repro here: https://github.com/rodoch/sapper-legacy-repro

This is simply a copy of the sapper-template repo with Sapper & Svelte versions bumped to 0.28.6 and 3.25.0 respectively. To reproduce the problem you need to use a 'legacy' browser. I have reproduced with Chrome <= 54 and Safari <= 9 (via BrowserStack and on an old Windows machine).

1. Start by opening the URL localhost:3000/blog. This page is styled correctly:

2. Next, navigate to the homepage. The content of this page is unstyled (e.g. the size of the success kid picture is unconstrained).

This behaviour is not evident if you start on the homepage and move to the blog, presumably because a sufficient set of styles have been applied on initial page load when moving in this direction. With more complex apps this behaviour can be observed on all navigations subsequent to the initial page load.

Expected behavior
The relevant styles should be applied with each route change.

Information about your Sapper Installation:

• The output of npx envinfo --system --npmPackages svelte,sapper,rollup,webpack --binaries --browsers

 System:
    OS: Windows 10 10.0.18363
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
    Memory: 5.08 GB / 15.88 GB
  Binaries:
    Node: 12.13.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.13.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 85.0.4183.102
    Edge: Spartan (44.18362.449.0)
    Internet Explorer: 11.0.18362.1
  npmPackages:
    rollup: ^2.3.4 => 2.26.11
    sapper: ^0.28.6 => 0.28.6
    svelte: ^3.25.0 => 3.25.0

• Your browser

Discussed above.

• Your hosting environment (i.e. Local, GCP/AWS/Azure, Vercel/Begin, etc...)

Local + Azure deployment.

• If it is an exported (npm run export) or dynamic application

Dynamic.

Severity
This is blocking any migration to v0.28 for me.

Additional context
I noticed a similar issue to this with modern browsers after initially migrating to v0.28.x. These issues appeared to be fixed in 0.28.6. I wonder if perhaps those changes didn't extend to the legacy mode.

I should also point out that all of necessary files (both JS and CSS) appear to be generated in __sapper__/build dir. They are simply not requested/applied on navigation.

I'm not sure if this part is relevant but it appears to be on a legacy browser that all assets which are loaded are requested from client/assets and not client/legacy/assets.

[benmccann]

Thanks for providing a way to reproduce @rodoch. I don't have a legacy browser available to use for testing at the moment, but I expect that #1508 would fix this. Could you give it a try and let me know?

[antony]

@benmccann you're on the browserstack account :)

[benmccann]

Sapper 0.28.7 is out now. Can you test with the new version?

[rodoch]

Thanks @benmccann. Bad news, I'm afraid this version is crashing completely on legacy browsers. I'm getting error 500 __inject_styles is not a function.

Can repro with the normal sapper-template, just bump the Sapper version number. Tested with Chrome 54, Firefox 53 on Browserstack, Mac & Windows machines.

[benmccann]

I just tried using our BrowserStack account and didn't have any issues loading the rollup template with IE 11.

The file __sapper__/build/client/legacy/client.0a8cbac2.js has import __inject_styles from './inject_styles.js';. The file __sapper__/build/client/legacy/inject_styles.js exists for me.

Though I think import is not supported in IE 11, so I'm not sure why it's working for me?

[rodoch]

I think IE11 is working for you because the client bundle isn't being executed at all (because, as you say, import is not supported) so what you're looking at is the server-rendered site. If I kill JavaScript in Chrome 54 it works for the same reason. As far as I can see the client JS bundle is broken in legacy browsers.

[benmccann]

It works for me in IE11 on both first page load and navigating between pages, but I do see an issue in Chrome 54:

Uncaught SyntaxError: Unexpected token import

I see that shimport is being used, but it looks like it's erroring:

Cannot read property 'default' of undefined

[rodoch]

It works for me on IE11 too but I suspect that is because the client JS is not executing at all and you are essentially navigating a server-rendered site. I could be way off though! I really don't know anything about shimport but according to the blurb on that repo it works for all kinds of import types.

[benmccann]

Yeah, I think you're right. I see an error in the console in IE 11:

Object doesn't support this action
shimport@1.0.1.js

[benmccann]

The error we're getting in Chrome 54 is unexpected token import on this line:

sapper/src/core/create_compilers/RollupCompiler.ts

Line 24 in cfa5a42

const href = new URL(file, import.meta.url);

[rodoch]

Is the import in import.meta.url the result of a dynamic import()? (I had a look at the source code but can't make out where import.meta.url is coming from.) Chrome doesn't support imported Javascript modules, dynamic or otherwise, until Chrome 61. Probably a similar timeline for Safari and Firefox. If this is the case that might go to explaining the problem.

[benmccann]

Sapper has a Rollup plugin that adds it. See my last comment that shows where it's coming from. We use shimport to support import statements in legacy browers, but it doesn't support import.meta.url currently, so perhaps we can add support there