[13.x] Fix Default DevCommands Registration From Framework Vendor Path

[hasinhayder]

Fix Default DevCommands Registration

Summary

This fixes Laravel's built-in DevCommands defaults being blocked by the vendor registration guard when the framework is installed under vendor/laravel/framework.

In a consuming application, Composer's post-autoload php artisan package:discover --ansi can fail while Laravel registers its default development commands:

DevCommands should be registered in application code, not within vendor packages. Attempted to register command: server

ArtisanServiceProvider registers Laravel's default development commands through:

DevCommands::registerDefaults();

registerDefaults() uses the existing public helpers:

self::artisan('serve --host=localhost', 'server');
self::artisan('queue:listen --tries=1 --timeout=0', 'queue');
self::artisan('pail --timeout=0', 'logs');
self::node('dev', 'vite');

Those helpers call DevCommands::register(), which correctly runs preventVendorRegistration() to stop third-party vendor packages from registering development commands automatically. However, Laravel framework code also lives inside vendor/laravel/framework in real applications, so the guard can accidentally block Laravel's own registerDefaults() path.

Solution

This change keeps registerDefaults() and the public registration helpers unchanged. The only production behavior change is that preventVendorRegistration() now allows the existing internal DevCommands::registerDefaults() call path before continuing to enforce the vendor guard for all other public registrations.

This preserves the intended behavior:

• Laravel's built-in default dev commands can register during framework boot.
• Application code can still register custom dev commands.
• Third-party vendor packages are still blocked from registering dev commands through the public API.

Tests

Added focused coverage for calling registerDefaults() from a simulated vendor path while keeping the existing vendor guard coverage passing.

vendor/bin/phpunit --filter FoundationDevCommandsTest
vendor/bin/pint --dirty

Notes

This does not modify ArtisanServiceProvider, does not change the default command definitions, and does not loosen the public vendor-registration guard.

[jackbayliss]

Should be fixed already via #60526 in https://github.com/laravel/framework/releases/tag/v13.16.1