Sage 9 + BrowserSync not loading any CSS at all on 'yarn run start'

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.

1 Like

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.

1 Like

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.

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.

1 Like

Yes, I have. Everything remains unstyled.

1 Like

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.

1 Like

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…

1 Like

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.

2 Likes

Got the same problem over here. Using a .local address an Google Chrome.

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

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.

3 Likes

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.

1 Like

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 ¯\_(ツ)_/¯

2 Likes

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?

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.

@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:


1 Like

So the question is: Why do some of us need cors enabled?
Would it make sense to add this to the official sage9 config?

Same issue here. This should definitely be in the default config since it’s required to work.

1 Like

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.