Asset files are not loading after a fresh Laravel Sail installation on MacOS

[tuto1902]

• Laravel Vite Plugin Version: 0.2.4
• Laravel Version: 9.19.0
• Node Version: 16.15.1
• NPM Version: 8.12.1

Description:

After a fresh installation of Laravel Sail and Laravel Breeze, css and js files are not loading in the browser

Steps To Reproduce:

curl -s "https://laravel.build/example-app" | bash

cd example-app
 
./vendor/bin/sail up

sail composer require laravel/breeze

sail artisan breeze:install

sail npm install && sail npm run dev

vite v2.9.13 dev server running at:

Local: http://localhost:5173/
Network: http://192.168.48.4:5173/

When I visit localhost/login, the console shows "Failed to load resource: bad URL" and these are the locations where the browser is looking for the resources:

http://0.0.0.0:5173/resources/css/app.css
http://0.0.0.0:5173/@vite/client
http://0.0.0.0:5173/resources/js/app.js

This is how the login page looks like

[simonwong1985hk]

me too

[timacdonald]

curl -s "https://laravel.build/example-app" | bash
cd example-app
./vendor/bin/sail up
sail composer require laravel/breeze
sail artisan breeze:install
sail npm install && sail npm run dev

I've just followed these steps verbatim and the site is running as expected on my MacOS machine...

Can you confirm the following:

1. You are running on MacOS (as discussed on Twitter).

2. The vite.config.js file contains only the following...

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel([
            'resources/css/app.css',
            'resources/js/app.js',
        ]),
    ],
});

3. Your docker-composer.yml contains the following...

        ports:
            - '${APP_PORT:-80}:80'
            - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'

4. You are not running npm run dev on your local machine as well as in Sail? i.e. two running instances.

[tuto1902]

I can confirm all of the above. Also, it appears the issue is limited to Safari. I tested the same address on Firefox and Chrome and the assets load fine. I haven't tested on Edge but I'm guessing it will work as well.

[tuto1902]

[tuto1902]

Another interesting development. When I turn off "Prevent cross-site tracking" in Safari's privacy preferences. The error message changes to this

[timacdonald]

I'm unable to replicate this in Safari. Everything is working as expected in Safari on my end. Toggling "Prevent cross-site tracking" on / off also has no impact for me.

Are you accessing localhost over HTTP or HTTPS?

[tuto1902]

I'm accessing localhost over HTTP. I don't know if it's relevant but I'm using an M1 Mac mini. Although, blaming it on apple silicon it's quite a leap.

[enkota]

The only way I could get things to work on Valet/Safari/SSL is with the following.

It would be nice not to have to explicitly set a domain path however as when you run npm run build and try to reload locally it'll error with Unable to locate file in Vite manifest: resources/css/app.css. when using the helper to load assets @vite(['resources/css/app.css', 'resources/js/app.js'])

vite.config.js

import {
    defineConfig
} from 'vite';
import laravel from 'laravel-vite-plugin';

const domain = "test.test";
const homedir = require("os").homedir();

export default defineConfig({
    plugins: [
        laravel({
            input: "resources/js/app.js",
            ssr: "resources/js/ssr.js",
        }),
    ],
    server: {
        https: {
            key: homedir + "/.config/valet/Certificates/" + domain + ".key",
            cert: homedir + "/.config/valet/Certificates/" + domain + ".crt",
        },
        host: domain,
        hmr: {
            host: domain,
        },
    },
});

[AdyGCode]

Hi @timacdonald,

I'm getting very similar issues to the other users, and I'm running on an Intel Mac, with Docker Desktop 4.10+

As I prefer to use MariaDB over MySQL, I used the steps:

curl -s "https://laravel.build/l9-vite?with=mariadb,redis,memcached,meilisearch,minio,selenium,mailhog" | bash
cd example-app
./vendor/bin/sail up
sail composer require laravel/breeze
sail artisan breeze:install
sail npm install && sail npm run dev

The vite.config.js file reads:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel([
            'resources/css/app.css',
            'resources/js/app.js',
        ]),
    ],
});

Docker compose file docker-compose.yml has the lines:

        ports:
            - '${APP_PORT:-80}:80'
            - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'

Tested using Chrome, Safari, Edge and Firefox.

• http://localhost:5173

  • Safari: BLANK
  • Chrome: No web page was found for the web address: http://localhost:5173/
  • Firefox: see Chrome
  • Edge: see Chrome

• http://localhost

  • Safari: Default welcome screen
  • Chrome: Default welcome screen
  • Firefox: Default welcome screen
  • Edge: Default welcome screen

• http://localhost/register

  • Safari: No assets loaded, as per @tuto1902
  • Chrome: Assets load
  • Firefox: Assets load
  • Edge: Assets load

On everything except Safari, I've managed to view the content as it should be for the default layout.

I use multiple browsers for testing to make sure that things are as I expect, so the fact that Safari is failing for some reason is a mild concern.

More of a concern is also that the http://localhost:5173/ is not rendering anything.

I have had no problems in the past with Mix.

[Fedeorlandau]

Facing a similar issue, blank page on port 3000.

I'm not using docker.

npm run dev

---

UPDATE with Solution:
If I run php artisan serve on another terminal + npm run dev and I access http://127.0.0.1:8000/ I get HMR working when I change any .vue file content 👍

[jessarcher]

@AdyGCode @Fedeorlandau Accessing the Vite dev server directly (http://localhost:3000 or http://localhost:5173, depending on whether you're running it inside Sail) is expected to return a blank screen at the moment as that's just where Vite serves assets for HMR. This has been improved with #57 as we'll now be outputting a default help screen to instruct users to run a dev server for Laravel.

[timacdonald]

@AdyGCode @tuto1902 are either of you using any ad blocking plugins or anything in Safari?

Could you confirm that the problem only exists in HMR mode? i.e. kill the dev server and run npm run build.

If you have valet installed could you try runnning valet stop and confirm the issue persists.

And finally, can you confirm if the issue persists when you have Safari in a "vanilla" state with no extra plugins or configuration? Please also try resetting the experimental features...

and then, if you have space, could you also try playing with these settings in Safari to see if you can make anything happen / get any further meaningful information from the console / requests.

[AdyGCode]

@timacdonald

• I'm not running valet at all.
• Also, not running any other web services other than using docker.
• Only have the Laravel site running inside docker.
• Safari is in 'vanilla' mode - same result
• Safari, reset the experimental features - same result
• Played with the settings as requested, including clearing cache between each test - no effect

I have little snitch running, but turned off filtering as a test, no effect.

HMR mode runs with assets compiled, the pages render as expected.

[AdyGCode]

@jessarcher

That's good to hear - someone who comes straight from mix to vite would not be familiar with that little idiosyncrasy.
May I suggest adding the message to the npm command results as well?

[AdyGCode]

@timacdonald

Tim, I modified the URIs for "vite" on the rendered page to localhost from 0.0.0.0 on Safari, and the page rendered.
I know this as I had purposely published the Breeze assets and modified the Login page, and yes gave the form field a pink background to highlight the rendering and change.

[tuto1902]

@AdyGCode @tuto1902 are either of you using any ad blocking plugins or anything in Safari?

Could you confirm that the problem only exists in HMR mode? i.e. kill the dev server and run npm run build.

If you have valet installed could you try runnning valet stop and confirm the issue persists.

And finally, can you confirm if the issue persists when you have Safari in a "vanilla" state with no extra plugins or configuration? Please also try resetting the experimental features...

and then, if you have space, could you also try playing with these settings in Safari to see if you can make anything happen / get any further meaningful information from the console / requests.

After trying out your suggestions:

• The issue only exists on HMR mode. After killing the dev server and running sail npm run build, the assets load without problem
• I have no extensions running on safari
• I Safari on vanilla mode (reset experimental features to default) and it had no effect. Same issue, no changes
• I Tried enabling/disabling all the suggested develop features (disable images, styles, etc). Same issue, no changes

[tuto1902]

@timacdonald A small development. Just like @AdyGCode, if I manually change the href value of the link in the head from 0.0.0.0 to localhost (Ctr+Cmd+C > right click > edit attribure). The page suddenly loads fine.

[AdyGCode]

@tuto1902, @jessarcher, @timacdonald

OK - I have found a workaround thanks to #42 plus the Spatie/Freek blade refresh settings.

Edited the vite.config.js file, and added the following before the plugins settings:

    server: {
        hmr: {
            host: 'localhost',
        },
    },

Also, added the Freek/Spatie 'fix' for auto-reload on blade file updates, in the plugins array, after the laravel entry:

     {
            name: 'blade',
            handleHotUpdate({ file, server }) {
                if (file.endsWith('.blade.php')) {
                    server.ws.send({
                        type: 'full-reload',
                        path: '*',
                    });
                }
            },
        }

Full Code for the vite.config.js is:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    server: {
        hmr: {
            host: 'localhost',
        },
    },
    plugins: [
        laravel([
            'resources/css/app.css',
            'resources/js/app.js',
        ]),
        {
            name: 'blade',
            handleHotUpdate({ file, server }) {
                if (file.endsWith('.blade.php')) {
                    server.ws.send({
                        type: 'full-reload',
                        path: '*',
                    });
                }
            },
        }
    ],
});

Results are the page rendering as expected in Safari (logo colour changed in this test):

[tuto1902]

@AdyGCode I tried your workaround but still doesn't work for me. I even tried setting server.host to localhost, which changed the address from 0.0.0.0 to localhost but the resources didn't load, which is all kind of confusing since changing the value manually in the rendered page to localhost actually loads the assets

[tuto1902]

This is a small video to demonstrate what I mean

Screen.Recording.2022-07-10.at.9.19.38.PM.mov

[AdyGCode]

@AdyGCode I tried your workaround but still doesn't work for me. I even tried setting server.host to localhost, which changed the address from 0.0.0.0 to localhost but the resources didn't load, which is all kind of confusing since changing the value manually in the rendered page to localhost actually loads the assets

@tuto1902
I know I'll probably be teaching you to suck eggs, but did you:

• CTRL+C to stop the npm run and then re-run using sail npm run dev?
• From time to time I will also sail down and then sail up after the changes if I am not sure changes were correctly picked up.

You may also want to run sail npm update just as a precaution.

The server.host (from what I read and recall) will not help when working with a sail/docker container - I believe the server.host needs to be 0.0.0.0 for docker/containers. The host, in this case, is the HMR (hot module reload?) and I set that to localhost and that seemed to work for me.

I also did force my cache to be cleared in Safari [CMD+OPT+E]. May also need to clear the Laravel cache as well [sail artisan cache:clear].

[tuto1902]

@AdyGCode I tried your workaround but still doesn't work for me. I even tried setting server.host to localhost, which changed the address from 0.0.0.0 to localhost but the resources didn't load, which is all kind of confusing since changing the value manually in the rendered page to localhost actually loads the assets

@tuto1902 I know I'll probably be teaching you to suck eggs, but did you:

• CTRL+C to stop the npm run and then re-run using sail npm run dev?
• From time to time I will also sail down and then sail up after the changes if I am not sure changes were correctly picked up.

You may also want to run sail npm update just as a precaution.

The server.host (from what I read and recall) will not help when working with a sail/docker container - I believe the server.host needs to be 0.0.0.0 for docker/containers. The host, in this case, is the HMR (hot module reload?) and I set that to localhost and that seemed to work for me.

I also did force my cache to be cleared in Safari [CMD+OPT+E]. May also need to clear the Laravel cache as well [sail artisan cache:clear].

@AdyGCode Thanks for the reply. I tried all the suggestions: sail down and sail up, Ctr+C, sail npm update, clearing cache from safari and from artisan. Nothing seems to work in my case. As a last resort, I'll try to get a hold of a different Mac and try to run a fresh install there to see how it goes.

Btw, your reply made me think of this immortal line 🤣

[tuto1902]

Ok, so I think this is just a problem with my Mac mini, or the Mac OS version, or the version of Safari, or maybe an ancient curse passed down by generations... In any case, I just ran my own steps to reproduce in an old MacBook Air with Mac OS Big Sur and sure enough, everything worked fine out of the box.

@timacdonald if there's no objection from anyone else, I think we can close this issue. 🤷🏻‍♂️

[AdyGCode]

Ok, so I think this is just a problem with my Mac mini, or the Mac OS version, or the version of Safari, or maybe an ancient curse passed down by generations... In any case, I just ran my own steps to reproduce in an old MacBook Air with Mac OS Big Sur and sure enough, everything worked fine out of the box.

That happens, and given my configuration is a bit wild, I was wondering the same.

If you get the chance to re-build the Mini then you may find it clears up the issue.
If not it, you have your answer for now.

@timacdonald if there's no objection from anyone else, I think we can close this issue. 🤷🏻‍♂️

@timacdonald and @tuto1902 - No problems closing, but it may be worth adding a note that in some situations, the HMR option under server may be required.

[driesvints]

Thanks all