Add Laravel named-resource and storage-disk intelligence

[shuvroroy]

Summary

Laravel frequently addresses configured services through strings, but those strings previously had uneven editor support. Some contexts only completed generic config keys, while others had no completion, navigation, references, hover, or validation.

This PR makes Laravel’s named resources first-class indexed symbols across the language server.

What changed

Storage disks

Storage disk names now receive full editor support in:

• Storage::disk()
• Storage::fake()
• Storage::persistentFake()
• Storage::forgetDisk()
• Array values passed to Storage::forgetDisk()
• Laravel’s #[Storage] contextual attribute

Names complete from filesystems.disks.*, navigate to their exact config declaration, provide family-specific hover information, and participate in find-references.

The implementation follows Laravel’s runtime semantics:

• disk() requires a configured disk and diagnoses unknown names.
• fake() and persistentFake() may introduce ad-hoc test disks, so they do not produce false unknown-disk diagnostics.
• forgetDisk() accepts optional scalar or array names.

Config-backed named resources

The same support now covers eight resource families:

Resource	Config subtree
Auth guards	auth.guards.*
Cache stores	cache.stores.*
Log channels	logging.channels.*
Storage disks	filesystems.disks.*
Database connections	database.connections.*
Queue connections	queue.connections.*
Mailers	mail.mailers.*
Broadcast connections	broadcasting.connections.*

Supported contexts include:

• Helpers such as auth('admin')
• Facades such as Auth::guard(), Cache::store(), DB::connection(), and Mail::mailer()
• Array arguments such as Log::stack(['daily', 'stderr'])
• Laravel contextual attributes
• auth:* and throttle:* middleware parameters
• Type-resolved connection() receivers
• Queueable onConnection() and onQueue() calls
• Model and queued-job $connection properties, including promoted properties

Source-defined names

This PR also indexes names that do not come from configuration:

• Rate limiters registered through RateLimiter::for()
• Queue names observed in typed onQueue() calls

Rate limiter names complete, navigate to their registration, and are validated in middleware and RateLimited constructors.

Queue names remain deliberately open-ended. Known literals are offered as completion candidates and references, but unseen names are not diagnosed because Laravel does not require queues to be declared centrally.

Editor behavior

Every supported resource family now provides:

• Completion scoped to the correct resource family
• Family-specific hover information
• Go-to-definition to the exact config entry or source registration
• Symmetric find-references between direct resource calls and generic config access
• Dedicated unknown-resource diagnostics where Laravel requires registration

For example, references to Cache::store('memory') are linked with direct access to config('cache.stores.memory').

Correctness

Resource extraction resolves semantic names instead of matching raw text. This supports facade aliases and fully qualified names while rejecting unrelated classes that happen to use names such as Cache, Route, or DB.

Named arguments, reordered arguments, modern and legacy arrays, nullable receivers, union types, inherited queue traits, and indirect model inheritance are covered.

Config and source indexes remain correct across:

• Unsaved editor buffers
• Dirty document close and disk restoration
• Watched file creation, modification, and deletion
• Package service-provider config files
• Runtime Config::set() registrations
• Framework default configuration
• Canonical and aliased filesystem paths

Performance and refactoring

The implementation was designed to keep completion and diagnostics hot paths inexpensive:

• Resource behavior is defined by one declarative descriptor table.
• Allocation-free family indexes avoid scanning every trigger for every PHP call.
• Completion context parsing uses borrowed prefixes rather than allocating strings.
• Typed receiver handling was split into a focused module.
• Queueable hierarchy resolution uses a visited breadth-first traversal, avoiding repeated work in diamond inheritance graphs.
• Typed receiver correlation uses one pre-sized offset map.
• Candidate-free files avoid unnecessary typed-cache write locking.
• Source-name membership checks avoid intermediate vectors and hash-set clones.
• Config scanning reuses path buffers and minimizes filesystem reads.
• Generation checks prevent stale concurrent scans from being published.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, examples/)
• I have updated the config schema (config-schema.json)
• I have added/updated tests to cover my changes
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant. This includes,
  for example, commit descriptions, PR descriptions, and code comments.

🤖 Generated with OpenAI Codex (5.6 Sol)

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[AJenbo]

12k lines is a lot for a single PR, it's also tackling several things at once, macOS specific path alias, how Laravel strings are handled in general, storage names, and existing string handeling. This makes it really hard for me to evaluate and understand what's happening.

[shuvroroy]

12k lines is a lot for a single PR, it's also tackling several things at once, macOS specific path alias, how Laravel strings are handled in general, storage names, and existing string handeling. This makes it really hard for me to evaluate and understand what's happening.

Yeah agree. I am thinking to use stacked pull requests feature for this PR. Already asked AI to do this for me. Will ping you once it's ready.

[shuvroroy]

Looks like GitHub’s native stacked PR feature requires every branch to be in the same repository; cross-fork stacks are explicitly unsupported 😅

[AJenbo]

You can just open multiple PRs, set them to draft and add a comment in the description

Depends on:
- #999

Then I can rebase once the next is ready.

[shuvroroy]

The split is ready. I replaced this oversized draft with focused dependent PRs:

• Fix filesystem aliases in vendor and Blade discovery #369 — filesystem alias handling (independent prerequisite)
• Add Laravel storage disk name intelligence #371 — Laravel storage disk names; depends on Fix filesystem aliases in vendor and Blade discovery #369
• Add Laravel config-backed resource name intelligence #372 — direct config-backed Laravel resource names; depends on Add Laravel storage disk name intelligence #371

#371 and #372 are drafts so each branch can be rebased as the layer below it lands. Their descriptions call out the exact scope, verification, coverage, and deferred follow-up work.

I’m closing #368 as superseded so review can continue on the smaller PRs. Thanks for the direction.