Repository navigation
Pre-release 4.2.128 → 4.2.127 — task 4.5 (foundation): facades and providers through v13's bootstrappers, no app/start files - #101
Merged
Conversation
agissept
force-pushed
the
pre-release/4.2.128
branch
from
October 2, 2026 09:21
2be8cff to
ce2ffe8
Compare
agissept
added this pull request to stack #102
October 5, 2026 06:14
agissept
force-pushed
the
pre-release/4.2.128
branch
8 times, most recently
from
October 6, 2026 07:18
ce3f534 to
b4a9e5b
Compare
…pers; no app/start files (task 4.5)
The start script now runs v13's RegisterFacades and RegisterProviders where
it set up the facades, the alias loader and the providers. Facades point at
the application after the configuration loads, as in v13.
RegisterProviders merges the providers given to withProviders() and those in
bootstrap/providers.php after app.providers, skipping classes that don't
exist. Application::configure() calls withProviders(), so the bootstrap file
is read by default. registerConfiguredProviders() registers the Illuminate
providers first, each group in its configured order. The package manifest
and the config cache come with the flip.
The start script no longer loads app/start/global.php or
app/start/{env}.php; v13 has no start files. The routes still load from
app/routes.php once the application has booted.
ProviderRepository's fresh manifest now carries the 'when' key, which it
was missing when no provider is deferred.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0169SsatCE8LhaTsQTPiGtVo
…v13 (task 4.5) The fork's app() helper returned the facades' application. Now that the facades are set after the configuration loads, as in v13, configuration files calling storage_path() or app() got null. v13's app() reads the container instance, which the application sets when it's constructed, so the helpers work before the facades are set. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0169SsatCE8LhaTsQTPiGtVo
agissept
force-pushed
the
pre-release/4.2.128
branch
from
October 6, 2026 07:19
b4a9e5b to
05b31a3
Compare
agissept
marked this pull request as ready for review
October 6, 2026 07:19
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task 4.5, foundation — facades and providers through v13's bootstrappers, no
app/startfilesStacks on #100. The start script set up the facades, the alias loader and the service providers itself, then loaded
app/start/global.phpandapp/start/{env}.phponce the application booted. v13 does the first three through itsRegisterFacadesandRegisterProvidersbootstrappers, and has no start files: an app does that work in its own service providers, listed inbootstrap/providers.php. This release ports those bootstrappers and v13'swithProviders(), and stops loading the start files.Changes
Illuminate\Foundation\Bootstrap\RegisterFacadesis v13's, without the package manifest's aliases:app.aliasesclass aliases.Illuminate\Foundation\Bootstrap\RegisterProvidersis v13's, without the config cache check and the framework's default providers:withProviders(), then those inbootstrap/providers.php, afterapp.providers;bootstrap/providers.phpare skipped.Application::registerConfiguredProviders()registers theIlluminate\providers first, then the others, each group in its configured order, as in v13. The L4.2 services manifest stays until the flip.ApplicationBuilder::withProviders()has v13's signature.Application::configure()calls it, as v13 does, sobootstrap/providers.phpis read by default.bootstrapPath()andgetBootstrapProvidersPath()come with it.app()resolves throughContainer::getInstance(), as in v13. It returned the facades' application, which is now set only after the configuration loads, so a configuration file callingstorage_path()would have failed. The application sets the container instance when it's constructed.app/start/global.phporapp/start/{env}.php. The routes still load fromapp/routes.phponce the application has booted.ProviderRepository's fresh manifest now carries thewhenkey. It was missing whenever no provider was deferred.FoundationApplicationBuilderTest:Illuminate\providers register before the others;withProviders()andbootstrap/providers.phpregister afterapp.providers, in that order, and a missing class is skipped;configure()readsbootstrap/providers.phpby default;storage_path()andapp()during bootstrap;bootstrapPath()andgetBootstrapProvidersPath().What changes
app/startfiles must move that code into a service provider, as the dicoding app does in its pair.Illuminate\provider now registers before the app's own providers. Each group keeps its order.app()and the path helpers still work there.app()no longer returns the facades' application. A test that stubbedapp()withFacade::setFacadeApplication()must useContainer::setInstance(), as one dicoding unit test now does.Verification
app/start/global.phpstill loaded;bootstrap/providers.phpignored;bootstrap/providers.phpmerged beforewithProviders();configure()not callingwithProviders();app()still returning the facades' application.feature/platform/framework-4.2.128-rc1). It moves its start files intoDicoding\Providers\AppServiceProvider, listed inbootstrap/providers.php. It ran with vendor installed from its lock, apart from the dev CLIsphpstan/phpstanandrector/rector, whose GitHub downloads are refused in this container:AppServiceProvider, with everyIlluminate\provider first and each group in its old order. The deferred services are the same.config()->all()is identical to 4.2.127 in production, local, testing and endtoend, apart fromapp.providers, which gainsAppServiceProvider.app()throughContainer::setInstance().php -S+server.php→index.php, and 7 artisan commands) and the 13 in-process request scenarios are identical to 4.2.127.Tag
There's no
4.2.128tag, as there are none for4.2.119–4.2.127: tag pushes are refused for this session. The app pins thepre-release/4.2.128branch (2be8cff3).🤖 Generated with Claude Code
https://claude.ai/code/session_0169SsatCE8LhaTsQTPiGtVo