-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to run Laravel under custom vendor location #131
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't change defaults. Make it configurable. Please.
hey @tillkruss can you expand a little on why you want to create configurable runtime dynamic variables with a worse user-experience for users instead of implementing a better default value? |
src/HandlerResolver.php
Outdated
@@ -72,7 +72,8 @@ private function laravel(): Application | |||
return $this->laravel; | |||
} | |||
|
|||
$bootstrapFile = getcwd() . '/bootstrap/app.php'; | |||
// ./vendor/bref/laravel-bridge/src/ | |||
$bootstrapFile = __DIR__ . '/../../../../bootstrap/app.php'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use realpath()
on both strings?
@deleugpn: I may simply not understand the use-case and this change looks like a potential breaking-change to me. Not changing the default behavior and allowing the 1 user who needs this to specify a custom path using an ENV variable seems like the lowest risk to me. |
What can I explain that would help you understand the use-case and show that this is not a breaking change?
I need this for myself, so now we're 2 users. The creation of configuration values increases the internal compleixty of the package as it leads to different execution path depending on how the end user interacts with it. The end user needing to override the default value with a configuration is also added burden. It's lose-lose situation for both users and maintainers. |
hey sorry folks, I've been using this branch in production for the last week and I haven't had time to clean this up to make it ready for merge. I haven't forgotten about it, I will get to it as soon as I finish my ongoing project. |
hey @mnapoli and @tillkruss, we have tested this out on AWS Lambda and it seems to be working as expected. The only last concern I have is in regards to Any suggestions on this? |
src/HandlerResolver.php
Outdated
@@ -96,4 +90,23 @@ private function laravel(): Application | |||
|
|||
return $this->laravel; | |||
} | |||
|
|||
private function resolveBootstrapLocation(): string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function seems to duplicate the other resolveBootstrapLocation()
function, but with a slightly different implementation (but same name), any reason for that?
Can we merge both functions into one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just addressed this
That's great, I added one comment inline.
How about namespacing the function? That would solve the problem without any weird thing? |
src/bref-init.php
Outdated
} | ||
|
||
// Going up 4 directories will get us from `vendor/brefphp/laravel-bridge/src` to the Laravel root folder | ||
return realpath(__DIR__ . '/../../../../'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @alustau this is breaking the invocation of php artisan config:cache
because realpath()
returns the folder without the last /
. We need to concatenate /
at the end of the string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This inline comment is not marked as "obsolete", is this resolved? I didn't see any new commits related to this, not sure what to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had forgotten to merge the PR that was addressing this 😅
Support PHP 8.3
Add slash in the end of laravel root path and namespacing function
hey @tillkruss and @mnapoli really sorry for how long this has dragged on. I just did a last round of refactoring to get all changes to a central place and address it in a more consistent manner. The goal is for the Whenever I'm deploying this change in my project right now to test it out inside AWS Lambda. |
I have not tested this in production yet, but I did a few tests on a staging environment with a real AWS Lambda. Everything is working as expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that there is a conflict due to my Pull Request #143 that was merged yesterday.
I have confirmed that the following modification works fine.
Hey @tillkruss and @mnapoli I just noticed I've been running this branch on production since December. Looks like I completely forgot to follow up on this. I just fixed the conflicts that @KentarouTakeda mentioned, but if we have no other objections, this is good to go. |
This is basically the same as #130.
There are 2 places right now that breaks when installing Laravel under a monorepo setup without the standard Laravel folder structure - the bref-init.php makes reference to
php artisan
in the root of the folder and the HandlerResolver container assumesbootstrap/app.php
inside/var/task
.The linked PR attempts (at request of @tillkruss) to implement an environment variable. That approach has a few downsides:
LARAVEL_
environment prefix outside of Laravel ownershipWe could still opt to use an environment variable if that's the preferred approach among the maintainers, but such variable should not be under the
LARAVEL_
namespace unless Laravel themselves provide the value by default.