Add Sail Support in Guidelines #329
Conversation
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com> # Conflicts: # all.php # src/Console/InstallCommand.php
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
.ai/pint/core.blade.php
Outdated
|
|
||
| - You must run `vendor/bin/pint --dirty` before finalizing changes to ensure your code matches the project's expected style. | ||
| - Do not run `vendor/bin/pint --test`, simply run `vendor/bin/pint` to fix any formatting issues. | ||
| - You must run `{{ $assist->bin() }}pint --dirty` before finalizing changes to ensure your code matches the project's expected style. |
There was a problem hiding this comment.
Typically, I feel like this would be written as {{ $assist->bin() }}/pint --dirty, so that $assist->bin() would return the path without the trailing slash for clarity. Thoughts?
There was a problem hiding this comment.
I have refactored this to use $assist->binCommand('pint') which feels much cleaner to me overall let me know what do you think.
src/Install/GuidelineConfig.php
Outdated
|
|
||
| public bool $laravelStyle = false; | ||
|
|
||
| public bool $enforceSail = false; |
There was a problem hiding this comment.
Is enforce the right term here? Feels off.
There was a problem hiding this comment.
Yes you are right enforce is too strict done refactoring from enforceSail -> usesSail
src/Console/InstallCommand.php
Outdated
| { | ||
| if ($this->shouldUseSail()) { | ||
| return ['laravel-boost', './vendor/bin/sail', 'artisan', 'boost:mcp']; | ||
| return ['laravel-boost', Sail::SAIL_BINARY_PATH, 'artisan', 'boost:mcp']; |
There was a problem hiding this comment.
I feel like all Sail related things should be encapsulated in Sail, right? So shouldn't this be (pseudo code): $sail->buildMcCommand()?
src/Install/GuidelineAssist.php
Outdated
| public function artisan(): string | ||
| { | ||
| return $this->config->enforceSail | ||
| ? Sail::SAIL_BINARY_PATH.' artisan' |
There was a problem hiding this comment.
Again, does it make more sense to have $sail->artisan()?
There was a problem hiding this comment.
I’m fine with either approach. My intent was to avoid over encapsulation and prevent Sail from being too closely tied to GuidelineAssist.php.
I’ve now refactored it to call the static methods from Sail instead. wdyt ?
joetannenbaum
left a comment
joetannenbaum
left a comment
There was a problem hiding this comment.
Close, perhaps a bit more tweaking based on my comments. Let me know what you think.
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
Signed-off-by: Pushpak Chhajed <pushpak1300@gmail.com>
This update introduces first class Sail support across the guidelines.
When a project installs Boost with Sail enabled, agent instructions now automatically switch to Sail specific commands rather than native CLI commands.
Example guidelinesBefore
- Run the minimum number of tests needed. Use php artisan test with a filename or filter.After (Sail selected during
boost:install)- Run the minimum number of tests needed. Use vendor/bin/sail artisan test with a filename or filter.Alongside these dynamic command replacements, this MR adds dedicated Sail usage guidance so LLM agents can reliably work inside Sail environments.