Okay now that makes sense 
Blocks a request if the requested type is “style” and the MIME type is not “text/css”
Disabling this in Trellis would certainly fix it, but I’d hope that it can be fixed in Sage itself. If a CSS file is being served, it should have the text/css MIME type.
Same issue experienced here…
I opened an issue over at the sage repo.
I’ve noticed that when you run Yarn build the dist folder will create styles folder and css files. But when you run Yarn start it will delete styles folder (but still keep scripts folder) inside dist. Can this be something? I’ve got the same issue right now, and not really aware of how to fix it. Tried the solution above, and it removed the Error with MIME bla bla. But got a new error that says mine .css files could not be found.
Are you experiencing a problem, or just the error message while running start?
start runs Browsersync which compiles styles and javascript in memory and injects them into the page while you work, so you can see your changes automatically. This can sometimes freak out your browser and throw some error messages, but as long as nothing is visually or functionally broken you should be fine ignoring those messages during development.
Its just an error, i am still seing styles and etc 
I sole this problem by clear the dist folder and then rebuild. In some comments says it’s does not impact anything. When id happened, the css file losted whitch page console this erro.
So is the fix to comment out
add_header X-Content-Type-Options nosniff always;
?
I assume this hasn’t been looked at since yet I face exactly the same problem…
Primary browser:
Chrome: Version 71.0.3578.98 (Official Build) (64-bit)
Also the same on:
Safari: Version 12.0 (14606.1.36.1.9)
Firefox Quantum: Latest
MacOS Mojave
Edit: Commenting out the above doesn’t work for me.
My set up slightly different though. I’m trying to achieve page specific css files.
In /assets/styles I have a newly created folder with a css file in it:
assets/styles/single-pages/home.scss
All there is in there is img { width: 100px; } for testing purposes.
config.js
"entry": {
"main": [
"./scripts/main.js",
"./styles/main.scss"
],
"home": [
"./styles/single-pages/home.scss"
],
"customizer": [
"./scripts/customizer.js"
]
}
setup.php
if(is_page('home')){
wp_enqueue_style('home.css', asset_path('styles/home.css'), false, null);
}
If I run yarn build and go to the static domain e.g. my-site.test, it works - no MIME errors.
If I THEN run yarn start I get MIME errors on both the static URL and the BrowserSync URL. However, updating the main.scss recompiles fine and the css updates display. Updates in home.scss trigger the recompile automatically, but the not only do the updated values inside not apply, the origin (previous/original) styles don’t apply at all.
With that said, doing exactly the same procedure completely breaks styles on the static URL (no styles applied at all, same MIME errors) - yet the BrowserSync URL works ok besides the home.scss not applying as described previously.
I have also tried just putting home.scss in the root assets/styles folder and ammending the paths accordingly - didn’t fix, same problem.
What do I need to do to fix this so I can have individual css files output on individual pages? Any reliable ‘true’ way to do this?
Hello!
As I said above:
If the errors you’re seeing are only happening while running yarn start and not in production or after running yarn build you might be overworking yourself to try to fix them. Browsers sometimes freak out at what Browsersync is trying to do and this is almost always safe to ignore.
Hi @MWDelaney, thanks for the response.
Well, sure it will work with yarn build but the fact still remains that its not working at all with yarn start.
This breaks browsersync development for me - at least in regards to page specific css files.
To reiterate, the original main.scss applies the styles to the page perfectly fine with yarn run despite the MIME errors but the home.scss doesn’t apply what so ever.
@anon73211272 when you comment out:
add_header X-Content-Type-Options nosniff always;
Ensure you have reloaded nginx for the new settings to take. Restart your watch task, and clear your browser cache.
If you are still experiencing the issue my next step would be to remove any comments in the start of your CSS files as this can trigger browsersync to serve the wrong filetype.
Finally browsersync can trigger this error if assets are missing and cannot be served. I noticed in your config.js your path to the home stylesheet is nested in the folder single-pages:
/styles/single-pages/home.scss
However in your setup.php you reference it at the root and not from the single-pages folder:
asset_path('styles/home.css')
@craigpearson Hi, thanks for the support.
I can confirm I restarted nginx with sudo service nginx reload inside the VM.
Watch has been restarted and browser cache is cleared.
There are no comments in home.scss or main.scss.
In regards to the paths, this is because the/single-pages/ folder never gets created. Even with yarn build:production. Instead, it dumps home.css into the same folder as main.css.
This is why I mentioned I tried putting the home.scss in the route instead of a folder in my OP but no success.
I’ve also tried adding the folder in asset_path('styles/home.css') but that doesn’t work either.
Something else I noticed is that it also creates a blank home.js file when I don’t have that defined anywhere else…
That github issue may address your problems. It’s a bit old, but it hasn’t been closed so I think it still applies.
Hi @alwaysblank, thanks for the reply.
It’s not something that breaks development so I can settle for it I guess.
But this MIME issue is a real blocker. It’s my first Fresh Roots stack project and I’m already stuck.
Did you read through the issue? It looks like it might have a workaround: https://github.com/roots/sage/issues/1911#issuecomment-314210060
Just to clarify the MIME type issue will be a result of browsersync not being able to inject the file due to the bug mentioned above. Browsersync will be erroring on the second stylesheet, that error will result in an incorrect MIME type as the error isn’t compiled CSS.
You should be able to confirm by using your browsers inspector, going to network, finding home.css and viewing the response and headers.
Very odd that your browser is sniffing MIME types when you’ve disabled it in nginx though
That worked great! Thanks for highlighting that.
So generally speaking, is this an issue with Sage or Webpack? Whilst the work around 'work’s, it seems really counter productive to enqueue JS files for CSS
IIRC it’s a webpack/browsersync implementation issue, so a little of both. Some people in the thread for that issue had success switching to Laravel Mix for the build process. I think this issue is one of the things that’ll be addressed in the next version of Sage.
This topic was automatically closed after 5 days. New replies are no longer allowed.