Flash of unstyled content in dev mode

[mishrasatyam]

Describe the bug
Css feels wierd while reload in dev environment. Works fine with build output

To Reproduce
Using below dependencies:
"@sveltejs/adapter-node": "next",
"@sveltejs/kit": "next",
"svelte": "^3.29.0",
"vite": "^2.1.0"

Video

css_wierd_on_reload.mp4

[benmccann]

This sounds like it could be coming from vitejs/vite#2282

[benmccann]

Hi all. This issue has been getting a lot of comments related to a bug in Svelte core that was fixed with Svelte 3.40.0 and SvelteKit 1.0.0-next.135. I'm hiding many of the most recent comments as off-topic because they're unrelated to the original SvelteKit issue here that existed before the Svelte bug was introduced

[FaberVitale]

I've got a similar issue with a scss file imported in routes/__layout.svelte

It seems that it does not load those styles in a render blocking manner.
It is a bit jarring because it does not then happen on the bundled version.

repo source

Dependencies

"@sveltejs/kit": "1.0.0-next.158"
"@sveltejs/adapter-static": 1.0.0-next.17
"svelte": "3.42.4"
"svelte-preprocess": "4.8.0"
"vite": "2.5.1"
"sass": "1.38.2"

computer macOs Catalina
node v14.17.3

[jaintarun]

If it helps anyone.. i found that my FOUC was only happening when I had references to CSS in my app.html
When I moved the CSS ref to the layout file, the FOUC issue went away.

[Augustin82]

We have the same issue on our project. The CSS is not in the app.html file, but is imported in the context script in the root __layout.svelte file.

EDIT: issue was solved by renaming the app.postcss file to app.css as explained here: svelte-add/svelte-add#137 (comment)

[bojanv55]

I have the same problem with latest svelte kit:

"@sveltejs/adapter-static": "^1.0.0-next.21",
    "@sveltejs/kit": "next",
    "@testing-library/jest-dom": "^5.15.0",
    "@testing-library/svelte": "^3.0.3",
    "@types/jest": "^27.0.2",
    "jest": "^27.3.1",
    "node-sass": "^6.0.1",
    "sass": "^1.43.3",
    "svelte": "^3.42.6",
    "svelte-check": "^2.2.6",
    "svelte-jester": "^2.1.5",
    "svelte-preprocess": "^4.9.4",

This is what I get (10sec pause on a frame so possible to read):

What I notices is that @include in global.scss are properly rendered in view-source, but all other elements are rendered later. Also, when using goto(), :global style is not cleared from the previous page.

Does not matter if I build it, or if I use it in dev - same behavior.

This is part of my __layout.svelte

<script>
  import '../global.scss';

and this is part of global.scss

@import "variables";
@import url('/static/font/inter/inter.css');
@import url('/static/font/phosphor/phosphor.css');

*,
*::before,
*::after {
  margin: 0;
  padding: 0;
  box-sizing: inherit;
}

[abohannon]

I'm running into this issue, as well. Working off of the base SvelteKit project. When I rename app.css to app.scss and update the import in __layout.svelte I get FOUC in development. Doesn't happen in production or local build.

svelte.config.js

import preprocess from 'svelte-preprocess';
import vercel from '@sveltejs/adapter-vercel';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: preprocess({ postcss: true }),
	kit: {
		adapter: vercel(),

		// hydrate the <div id="svelte"> element in src/app.html
		target: '#svelte'
	}
};

export default config;

postcss.config.cjs

const autoprefixer = require('autoprefixer');

module.exports = {
	plugins: [autoprefixer]
};

[thebrianbug]

I get this issue as well

svelte.config.js

import adapter from '@sveltejs/adapter-auto';
import preprocess from 'svelte-preprocess';

/** @type {import('@sveltejs/kit').Config} */
const config = {
  // Consult https://github.com/sveltejs/svelte-preprocess
  // for more information about preprocessors
  preprocess: [
    preprocess({
      postcss: true,
    }),
  ],

  kit: {
    adapter: adapter(),

    // hydrate the <div id="svelte"> element in src/app.html
    target: '#svelte',
  },
};

export default config;

postcss.config.cjs

const tailwindcss = require('tailwindcss');
const autoprefixer = require('autoprefixer');
const cssnano = require('cssnano');

const mode = process.env.NODE_ENV;
const dev = mode === 'development';

const config = {
  plugins: [
    tailwindcss(), // first load TailwindCSS
    autoprefixer(), // then run autoprefixer
    !dev && // optimize the code for production
      cssnano({
        preset: 'default',
      }),
  ],
};

module.exports = config;

tailwind.config.cjs

const config = {
  mode: 'jit',
  content: ['./src/**/*.{html,js,svelte,ts}'],
  theme: {
    extend: {},
  },
  // Only add this if you installed the TailwindCSS-plugins:
  plugins: [require('@tailwindcss/typography'), require('@tailwindcss/forms')],
};

module.exports = config;

index.svelte

<script>
  // src/routes/__layout.svelte
  import "../app.pcss";
</script>

<h1>Welcome to SvelteKit</h1>
<p>Visit <a href="https://kit.svelte.dev">kit.svelte.dev</a> to read the documentation</p>

If I rename app.pcss to app.css there is no flash.

index.svelte

<script>
  // src/routes/__layout.svelte
  import "../app.css"; // Changed from .pcss
</script>

<h1>Welcome to SvelteKit</h1>
<p>Visit <a href="https://kit.svelte.dev">kit.svelte.dev</a> to read the documentation</p>

[TheophileMot]

I have this problem as well, in both development and production. I'm using Tailwind and Carbon components (which requires SCSS).

---

Edit: I was missing an adapter; after adding it, the problem is mitigated (but not solved) for production. It still flashes occasionally, just more briefly.

[skrenes]

I found the answer everyone! Give that person a thumbs up! No need to modify your svelte.config.js file either. Basically instead of importing the scss file at the top of __layout.svelte, remove that and instead add the style with the defined language and global keyword. The global keyword is the secret sauce to ensure it's not locally scoped.

More explicitly, remove this from the top of __layout.svelte:

import '../app.scss';

And add this to the bottom:

<style lang="scss" global>
  @import '../app.scss';
</style>

[timwis]

@skrenes that did it—thanks!

Only thing is it threw an error that I can only have one top-level <style> component (I had another non-global one for my layout's actual styles). I moved these styles inside the global one to fix it, though that feels like a bit of a workaround. I guess it's no difference since it's the root layout anyway?

[skrenes]

Yeah, I guess while it feels dirty polluting the global styles, __layout.svelte is always the top-level component, so semantically it's the same thing. But I'm not an authority on SvelteKit best practice, so perhaps someone else has a better way.

[joshpierce]

So if anyone else comes across this issue while using __layout.reset.svelte it's important to import '../app.css' (or in my case in a subfolder import '../../app.css'; however nested your layout reset might be) in your layout reset component. I had created this layout from scratch and hadn't included that so I was getting a nasty FOUC. 😅

If it's helpful, look at how your root level __layout.svelte file is doing this import, and mimic that in your reset file.

[Rich-Harris]

Alright, I figured out what's going on here. Turns out I even anticipated this bug and added a TODO at some point:

kit/packages/kit/src/core/dev/plugin.js

Lines 82 to 86 in 623fa49

	// TODO what about .scss files, etc?
	if (
	dep.file.endsWith('.css') ||
	(query.has('svelte') && query.get('type') === 'style')
	) {

The easy fix would be to just add .scss and whatever else to the list of extensions it recognises, though that feels like a bit of a kludge. Open to any other bright ideas about how to identify that Vite is treating a module as CSS!

[bluwy]

Vite has a hardcoded list of CSS langs too. There isn't an API or trick to share the code from Vite, so a compromise now is to copy it over.

[elliott-with-the-longest-name-on-github]

I can't think of a better solution than hardcoding the CSS variants in. Given that the smart people over at Vite haven't come up with anything either, I think it may be the best choice. One possibility would be to hardcode our list here, leaving a TODO to revisit it occasionally to see if there's a better way -- better to provide a stable fix now (I mean, really, how often is there a new CSS filetype variant) and perhaps revisit later...

If we want to go with the hardcoded approach, I can work up a pull request.

[gaarf]

I didn't have the flash of unstyled in dev before #4882, but now I do :-(

[benmccann]

@gaarf can you file a new issue with steps to reproduce and then link to it from here? We'd need more info...

[Conduitry]

It sounds like the regression may have been #4987 and would be fixed by #4990.

[gaarf]

@benmccann @Conduitry after cleaning build and updating to @sveltejs/[email protected], things are working as expected, no more flash in dev 🥳