HALP! Laravel Mix not using my app.css

is your project laravel6.test, or is that a different project?

What code do you have in your header to load the css.

Have you looked at the file in public/css/app.css with your code editor? Is it compiled correctly?

Hi Snapey, thanks for getting back to me. Here's how I have my projects configured in homestead.yaml:

folders:

- map: C:\webcode\perspectives\Perspectives


  to: /home/vagrant/Code/perspectives

- map: C:\webcode\perspectives\laravel6

  to: /home/vagrant/Code/laravel6

sites:

- map: homestead.test

  to: /home/vagrant/Code/perspectives/public

- map: laravel6.test

  to: /home/vagrant/Code/laravel6/public

The laravel6/public/css/app.css in my code editor is compiled correctly, yes. It's not until the webpage source in the browser that the css links to that very basic body { color: black; } .css file

Does anyone possibly have enough knowledge of webpack to know what's going wrong?

Does anyone possibly have enough knowledge of webpack to know what's going wrong?

You have said that webpack output is correct

So the problem is the way you link to the file in your view - I did ask for this, but you showed a lot of irrelevant stuff instead

No, it’s something webpack does under the hood with the file name app.css specifically. It overrides the asset path or something, i think it has to do with vue.cli. The work around didn’t work until i removed the asset() helper AND renamed app.css. Reinstalling npm, rm -rd node_modules, and npm cache clear didn’t resolve app.css

if you use version in mix and then use the mix helper in the blade view then you are guaranteed to be cache busting. But you don't seem that advanced to be worrying about cache busting

It seems to be an aliasing issue, not a stale caching issue, unless you’re saying you can leverage cache busting to point it to a manual file location

What code do you have in your header to load the css.

My last attempt

That’s a good idea to check, I’m afk right now but I’ll let you know if i see something interesting in the header

Referring to https://laracasts.com/discuss/channels/vue/registerbladephp-and-loginbladephp-vue-styles-not-applying

I’ll let you know if i see something interesting in the header

The layout header is where this stuff goes.

First off, I'd like to apologize if I was irritable or annoying the other day. It's rare that I work 40+ hours on a programming issue and get absolutely nowhere on it. It helped to walk away for a day.

I looked into app.blade.php header, which was ultimately where I replaced:

< link href="{{ asset('css/app.css') }}" rel="stylesheet" >

-with-

< link href="/css/try.css" rel="stylesheet" >

I give up on this now that I have a workaround. it's a much deeper issue with how webpack is aliasing app.css. If anyone has insight into where the app stores the files keyed by the urls in the asset() function:

function asset($path, $secure = null)
{
    return app('url')->asset($path, $secure);
}

That might help me trace a little better how webpack is linking things and from where it's ultimately plugging in this default css file from.

Webpack does not alias app.css. I'm not sure where you have this idea from.

Please check the URL created when you use {{ asset('css/app.css') }} (look in browser source)

it could be that your APP_URL is wrong

Please also check https://laravel.com/docs/7.x/mix#versioning-and-cache-busting

http://laravel6.test/css/app.css is the url that's created. I made sure that APP_URL was laravel6.test, and APP_NAME was laravel6. No change.

I got the aliasing idea from this: https://dev.to/acro5piano/laravel-tips-set-resolve-alias-in-laravel-mix-6f5

I'll admit I'm groping in the dark here, I've been working with laravel for like 2 weeks, now, so please try to be a little patient if I'm describing some of the surrounding context inaccurately. That article seemed to be on the right track to me at least at the time because it was talking about the default of the source that the app uses, which I figured was pointing to the top of my shared directory, and not to the projects I created as subdirectories to the shared top level directory. I didn't know if the webpack was taking configuration information from homestead.yaml on npm run dev, and trying to find the public directory relative to one directory too high.

So if you load the page http://laravel6.test/css/app.css does it show what you want??

If not does this show it http://laravel6.test/css/app.css?v=1

Loading http://laravel6.test/css/app.css shows me the same erroneous css: body { color: black; }. I haven’t tried versioning yet...but at that point i figure it’s another workaround and might as well just hardcode the css to a renamed file in public with the copied contents anyway. I appreciate everyone’s help, I can try other things if people are curious enough what’s going on, but I’m personally satisfied with that work around and wouldn’t want to keep troubling the community and jumping this issue to the top of the discussion board.

Just curious, have you viewed https://laracasts.com/series/laravel-6-from-scratch

Episode 17

It will help. Also just a small suggestion, until you get a handle on this, I'd follow Taylor's instructions. Not knocking other tutorials.

Well yes it just sounds like cache. Use versioning. It isn’t difficult and will take you less than a minute to set up.

https://laravel.com/docs/7.x/mix#versioning-and-cache-busting

I have been working my way through that tutorial and it’s great! Everything has worked so smoothly until this point which is what’s such a headscratcher. It’s uncharacteristically difficult to debug compared to the rest of my laravel/laracast experience. The only thing I’ve done differently than the instructor other than deving on windows is add an extra database for a second domain in my homestead.yaml in case later tutorials came back to the first db.

I’ll give that a try tonight. It’s curious it could be a caching issue, i keep running $ npm cache clean —force

Without luck, workaround aside. Unless there’s multiple caches that I’m not covering with npm cache clean. Im also recursively deleting node_modules regularly as i try new things

Okay, reading that article, obviously the browser cache is different than the npm cache. I’ll try a different browser tonight and give it a go.

You beautiful animals, versioning did it! Incidentally, what are the best practices for cache-busting? Obviously it's got to slow down browsing any time the source files update, does it slow down web serving EVERY time? Does it save headaches during dev but is something to remove in production, or is it always good practice to apply?

Also, breadcrumbs for anyone else who struggles with this issue, it probably WAS a combination of the stale browser cache AND APP_URL in the .env file not being set appropriately. If you verify that your public/css/app.css file seemed to compile okay, try a different browser, or clearing cache and cookies if you insist on a particular browser.