You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, rootUrl is compiled from APP_URL when laroute:generate is executed. As far as I can tell, rootUrl is only ever used when laroute.absolute is false (default). Otherwise, it is not needed.
Using relative path generation assumes URIs are mounted under the domain name, not considering an application that might be hosted in a subdirectory of that domain. Laravel's UrlGenerator doesn't care much about this because it relies on Symfony's Request to generate a correct URI up to the point it takes over. Using absolute URLs when generating is a way around this since JavaScript has no way of telling the difference between what's a subdirectory and what's route.
Here's my specific problem:
I do local development on an application and I serve it from http://local.dev.
My production environment is hosted from http://example.org/application.
I use webpack to handle the bundling of the resultant laroute.js file generated by this package. I do not bundle assets in production; thus, the only .env available at compile-time is my local one.
So, if I pack everything up locally and use absolute URLs, I end up with a production application attempting to query http://local.dev/generated/path when in fact, I want http://example.org/application/generated/path. Previous to discovering this package, I was doing something fairly similar: creating a JavaScript object populated with data from the backend. The difference was that I didn't need to support parameterized routes during prototyping and now I do, so I'm delighted to find this package! 😁
However, I would like to contribute a means of determining root URL at runtime, based on either the .env#APP_URL configuration OR by generating it and disregarding what is in .env#APP_URL.
All this to say, would you be interested in such a contribution and if so, do you have any specific constraints towards development? I've got a local patch that works for me but it requires something like this in my base template (which actually works alright and is reasonable, to me):
Essentially, exposing configuration to userland to be changed at runtime, while also allowing compile-time generation from your published vendor configuration.
The text was updated successfully, but these errors were encountered:
Currently,
rootUrl
is compiled fromAPP_URL
whenlaroute:generate
is executed. As far as I can tell,rootUrl
is only ever used whenlaroute.absolute
isfalse
(default). Otherwise, it is not needed.Using relative path generation assumes URIs are mounted under the domain name, not considering an application that might be hosted in a subdirectory of that domain. Laravel's UrlGenerator doesn't care much about this because it relies on Symfony's
Request
to generate a correct URI up to the point it takes over. Using absolute URLs when generating is a way around this since JavaScript has no way of telling the difference between what's a subdirectory and what's route.Here's my specific problem:
http://local.dev
.http://example.org/application
.laroute.js
file generated by this package. I do not bundle assets in production; thus, the only.env
available at compile-time is my local one.So, if I pack everything up locally and use absolute URLs, I end up with a production application attempting to query
http://local.dev/generated/path
when in fact, I wanthttp://example.org/application/generated/path
. Previous to discovering this package, I was doing something fairly similar: creating a JavaScript object populated with data from the backend. The difference was that I didn't need to support parameterized routes during prototyping and now I do, so I'm delighted to find this package! 😁However, I would like to contribute a means of determining root URL at runtime, based on either the
.env#APP_URL
configuration OR by generating it and disregarding what is in.env#APP_URL
.All this to say, would you be interested in such a contribution and if so, do you have any specific constraints towards development? I've got a local patch that works for me but it requires something like this in my base template (which actually works alright and is reasonable, to me):
Essentially, exposing configuration to userland to be changed at runtime, while also allowing compile-time generation from your published vendor configuration.
The text was updated successfully, but these errors were encountered: