# Sage 9 + BrowserSync not loading any CSS at all on 'yarn run start' **URL:** https://discourse.roots.io/t/sage-9-browsersync-not-loading-any-css-at-all-on-yarn-run-start/11332 **Category:** sage **Tags:** webpack **Created:** 2018-01-16T22:56:13Z **Posts:** 30 ## Post 1 by @wbiggs — 2018-01-16T22:56:14Z Hi all. I’m having a weird issue getting any CSS to load thru browsersync. When I do `yarn run build`, the CSS is compiled and loads fine. However, when doing `yarn run start` instead, all the HTML loads, but none of the CSS does - I just get unstyled content. I don’t get any console errors (just the usual `GET main.css net::ERR_ABORTED` error) or any messages in the terminal. I can’t tell why this is happening; there are no errors anywhere at all. Any ideas? My config.json is correctly configured, as is everything else (as far as I can tell). This is a pain. --- ## Post 2 by @MWDelaney — 2018-01-17T00:17:11Z > [@wbiggs](#): > > My config.json is correctly configured This is tough to confirm without seeing the actual file. --- ## Post 3 by @strarsis — 2018-01-17T02:30:59Z I also have a similar issue. I never got styles hot reloading working. Because I am mostly using the web developer console (browser inspector), it isn’t that bad to manually rebuild from time to time – but a hot reload would be definitely an improvement. --- ## Post 4 by @wbiggs — 2018-01-17T03:47:13Z ``` { "entry": { "main": [ "./scripts/main.js", "./styles/main.scss" ], "customizer": [ "./scripts/customizer.js" ] }, "publicPath": "/wp-content/themes/wbiggs", "devUrl": "http://localhost", "proxyUrl": "http://localhost:3000", "cacheBusting": "[name]_[hash:8]", "watch": [ "app/**/*.php", "config/**/*.php", "resources/views/**/*.php" ] } ``` publicPath is set to the correct path afaik. --- ## Post 5 by @wbiggs — 2018-01-17T17:35:48Z This is just so weird. I can’t find an issue anywhere that could be causing this. It’s really slowing down my work right now - waiting 8 seconds for everything to build whenever I make a minor CSS change isn’t exactly efficient. Urghhh. --- ## Post 6 by @MWDelaney — 2018-01-17T17:39:43Z Well, the speed of the build and it not building and injecting at all (your original problem) are different things. I’ll occasionally see unstyled content on the first load of a browsersync session; I usually either SHIFT-reload or make a stylesheet change (or just re-save a file) and then SHIFT-refresh again for good measure and it fixes itself. If instead you’re having problems with slow builds, you could try removing scss lines from `main.scss` one by one to see if a particular stylesheet is taking a long time to build? --- ## Post 7 by @wbiggs — 2018-01-17T17:41:52Z Oh no, the build speed isn’t the issue - it’s just an annoyance to have to build every time I make an edit rather than be able to use `yarn run start`. Hard refreshing and re-saving don’t do anything for me, btw. --- ## Post 8 by @MWDelaney — 2018-01-17T17:44:58Z And you’re pointing your browser to `http://localhost:3000`? Do you see browsersync messages in the top right of the browser window when you save a file? When you build manually are you using `yarn build` or `yarn build:production`? --- ## Post 9 by @wbiggs — 2018-01-17T17:47:09Z I see browsersync messages, and I’m pointing my browser to that link. When I build manually I’m just using `yarn build`. I tried doing a clean install of Sage and just dropping the styles and views back in and the problem still occurs. --- ## Post 10 by @strarsis — 2018-01-17T17:53:37Z I also see a rebuild message `webpack built [some hash] in ms` directly in browser (browsersync proxied) after saving a file modification, but nothing changes in browser. --- ## Post 11 by @wbiggs — 2018-01-17T17:55:33Z I think we’re having different issues - modified views (.blade.php files) get injected for me, but styles don’t - not when `yarn start` is run, and not when files are modified. EDIT: I misunderstood the above post, lol. When I save SCSS files, everything properly recompiles and I get the same ‘webpack built…’ message, but the CSS still isn’t injected and everything remains unstyled. --- ## Post 12 by @strarsis — 2018-01-17T17:58:23Z Yes, indeed, styles are not injected for me, too. Which is indeed the biggest issue because usually I work on them most of the time. --- ## Post 13 by @MWDelaney — 2018-01-17T18:05:02Z Just for ha-has, have you tried force-refreshing a few times after seeing a recompile message? Like I said, I see this sometimes but a force-refresh usually kicks it into gear. --- ## Post 14 by @wbiggs — 2018-01-17T18:05:29Z Yes, I have. Everything remains unstyled. --- ## Post 15 by @strarsis — 2018-01-17T18:11:41Z Me, too. Restarted the browser, incognito mode, cleared everything, used different browser, etc. Saving a stylesheet results indeed in an automatic rebuild, I even see stylelint errors in browser. But the styles themselves aren’t applied to the page. Edit: I am running the watch script on WSL/Bash on Windows, with native file system watching. --- ## Post 16 by @wbiggs — 2018-01-17T19:18:20Z > Edit: I am running the watch script on WSL/Bash on Windows, with native file system watching. So am I! Looks like we found a common reason this could be not working. Hmmmmmmmm… --- ## Post 17 by @Simeon — 2018-01-17T22:00:39Z I get this problem regularly, where the .test site doesn’t get the CSS for a long time. And a (likely) related problem where the BrowserSync CSS doesn’t update when changes are saved. In both cases I need to hard-reload over and over to see updates. --- ## Post 18 by @Burni601 — 2018-01-19T15:21:10Z Got the same problem over here. Using a .local address an Google Chrome. --- ## Post 19 by @ben — 2018-01-22T01:38:24Z Sage 9 issues during `yarn run start` usually mean that your `publicPath` and/or `devUrl` in `resources/assets/config.json` are incorrect Can anyone confirm that this happens on a completely unmodified version of Sage 9 with the proper `publicPath` and `devUrl`? If you’ve already made changes to your styles or JS, it’s possible you’re hitting a linting error that isn’t being shown --- ## Post 20 by @Simeon — 2018-01-22T03:13:17Z Would be interested to see if this fixes for others. Think there’s an issue with the JS loading, and that manifests in not loading the CSS updates. Try adding `"headers": { "Access-Control-Allow-Origin": "*" },` to `config.json` That appears to be fixing it here now. The page will still load with no assets/js/css at first, but after a reload or two it all works. **Also:** make sure you your `proxyUrl` is secure with `https` as well. Have tested the above on a fresh install. Was able to duplicate my problem and then fix it with the above. --- ## Post 21 by @Nicolai_Olesen — 2018-01-26T12:18:08Z I had the same issue. **yarn run start** didn’t compile to dist/styles. I had removed `@php(wp_footer())` in app.blade.php by accident and by reverting this webpack started to work again. --- ## Post 23 by @wbiggs — 2018-01-26T23:05:13Z I solved it. It’s so stupid, oh my god. So because my design doesn’t actually have a footer element, I never bothered to add any of the footer code to my page. But wp\_footer() isn’t a footer element, it’s how WordPress injects javascript files to the bottom of your body. So I added it. And it fixed the whole problem - it works flawlessly now. God, I feel dumb. Hopefully this helps someone else, too - I’m probably the only one to make this mistake considering how obvious it is but maybe not ¯\_(ツ)\_/¯ --- ## Post 24 by @strarsis — 2018-03-01T23:05:57Z The theme still got the `wp_footer()`, so this isn’t the issue in my case. I noticed that in console the following is logged on a (failed) hot-reload (after saving source styles): ``` Failed to load http://localhost:3000/app/themes/the-theme/dist/57efeac3e396fa2f9996.hot-update.json: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.8.101:3000' is therefore not allowed access. Uncaught (in promise) Error: Manifest request to http://localhost:3000/app/themes/the-theme/dist/57efeac3e396fa2f9996.hot-update.json timed out. at XMLHttpRequest.request.onreadystatechange (bootstrap 57efeac3e396fa2f9996:38) ``` @Simeon: I added the ``` "headers": { "Access-Control-Allow-Origin": "*" }, ``` to `config.json`, as top level field. – Am I still missing something here? --- ## Post 25 by @Simeon — 2018-03-01T23:17:40Z Yeah it’s not a perfect fix. Occasionally I’ll check the inspector and it’ll say it can’t find the `main.js` file at all, but then if you try and access it directly it loads, and then the site does as well. --- ## Post 26 by @strarsis — 2018-03-01T23:41:01Z @Simeon: Edit: According to author BrowserSync has to be configured with `advanced` key: ``` new BrowserSyncPlugin({ target, open: config.open, proxyUrl: config.proxyUrl, watch: config.watch, delay: 500, advanced: { browserSync: { cors: true, }, }, }), ``` Related issues: > > --- ## Post 27 by @strarsis — 2018-03-04T21:45:17Z So the question is: Why do some of us need `cors` enabled? Would it make sense to add this to the official sage9 config? --- ## Post 28 by @octoxan — 2018-04-03T15:26:46Z Same issue here. This should definitely be in the default config since it’s required to work. --- ## Post 29 by @ben — 2018-04-04T14:56:28Z > [@octoxan](#): > > This should definitely be in the default config since it’s required to work. This is definitely not required to work by default for everyone. This is definitely related to your local development webserver setup. Closing this thread as it hasn’t been related to the solution posted since someone else posted with an unrelated issue. --- ## Post 30 by @ben — 2018-04-04T15:01:36Z