@trevorpan Example of proxying:
Imagine this in the .env file:
SOMETHING_ENABLED=true
Then you have a config file (/config/something.php) using that value:
<?php
return [
'enabled' => env('SOMETHING_ENABLED', false),
];
Then anywhere else in your app, instead of using env('SOMETHING_ENABLED) to get the value, you would use config('something.enabled'). The benefit for this is that the config file can be cached, and you limit the risk of exposing important .env values to other parts of the app.
Now back to Vite: import.meta.something is a standard JS feature, and you can only use it in a JavaScript file.
As Blade is PHP and outputs HTML, it has no idea that there is a value that exists behind import.meta and that you would like to use this value. Vite doesn’t touch your Blade files.
That’s why a possible solution would be, in your Blade template, to refer to that value using not env() but config('something.my_url), itself referring to a /config/something.php containing env('VITE_APP_URL'):
return [
'my_url' => env('VITE_APP_URL'),
];
So you have basically to ways to use your .env variables:
- PHP: .env -> config file ->
config()
- JS .env ->
import.meta.env (thanks to Vite)