After updating to Valet 2.0.1, any project being served by the LaravelValetDriver is 404ing on assets nested within a static folder.
A call to a CSS file like this one, results in a 404.
asset('static/css/app.css')
We use this pattern pretty regularly, and this issue did not exist before updating to 2.0.1. After initially encountering the issue I removed Valet entirely and did a fresh composer global require laravel/valet, but no luck.
Can you share a small example project that demonstrates the issue? Can't replicate it here.



Thanks for looking into this so quickly.
Attached are two screenshots - The first screenshot shows what happens when my app references the CSS file from a folder named test instead of static. The second shot is what happens when I reference that exact same file but placed inside of a folder named static.
Both screenshots show the file browser, and blade view where I'm using {{ asset('static/css/app.css') }} or {{ asset('test/css/app.css') }} to reference the file. You can see in the console window that the app.css file is 404ing for some reason, even though, according to the file browser, it exists in both places.


I also just did a super quick test on a brand new project that had never been linked to Valet in the past and I didn't get this issue. Not sure how or why that would matter. Hope it helps.
Thanks,
Justen
On second look. I think the issue might be related to specific file types. I just ran a fresh test again, but made sure to test images (JPG) and CSS files. The CSS file and the image both 404 in the console, but the image displays!

Ah ok I can replicate this now, I know what the issue is, will explore how to fix it. I have one solution that I know will work but is gross :)
That's great news - I thought I was loosing my mind for a minute there!
is there anything specific I can do to my Valet install to remedy the issue in the interim?
So the issue is we use the /static prefix to proxy static asset requests back to nginx so we don't have to serve them through PHP:
https://github.com/laravel/valet/blob/master/cli/stubs/valet.conf#L6-L10
https://github.com/laravel/valet/blob/master/cli/drivers/ValetDriver.php#L141
Those are the only two places (plus the HTTPS valet.conf files) where that string is mentioned.
It sounds like the solution is going to be to pick a different prefix with a much lower chance of collision, probably some sort of hash or something.
Still sucks because it's impossible to completely eliminate the chance of a collision but we can definitely make it immensely lower to the point where it's a non issue. Will have to think on the best prefix to use, I suppose some sort of long-ish random string is fine, just seems so arbitrary :)
@justenh Switch to dev-master and run valet install again 馃憤馃徎
Ride the bleeding edge 馃槑
@adamwathan 馃槑
Thanks, that did the trick!
Most helpful comment
Ah ok I can replicate this now, I know what the issue is, will explore how to fix it. I have one solution that I know will work but is gross :)