Feature Description
Summary
Laravel Idea already autocompletes the names of props on custom Blade components (via ide.json → blade.components). It also already supports value autocompletion for PHP helpers and methods through completions[].condition + staticStrings.
What's missing is the natural bridge between the two: value autocompletion for Blade component attributes. For UI packages that follow the shadcn/Radix vocabulary (variant, size, tone, color, side, align…), this is the single most repetitive typing spot in a template.
Motivating example
<hw:button variant="outline" size="sm">Cancel</hw:button>
variant on <hw:button> accepts exactly default | destructive | outline | secondary | ghost | link. size accepts xs | sm | default | lg | icon-xs | icon-sm | icon | icon-lg. Today the developer has to remember or look up these lists — the plugin has no way to surface them.
The same pattern repeats across every component library in the ecosystem: Flux, Filament, MaryUI, TallStack UI, laravel-hotwire, and any shadcn-inspired preset.
Proposal
Two forms, in order of preference:
A) Infer from PHPDoc literal-string unions on promoted constructor props (preferred)
Laravel Idea already reads component constructors for prop names. Reading a literal-string union from the declared type would make the plugin infer allowed values with no ide.json involvement:
class Button extends Component
{
public function __construct(
/** @var 'default'|'destructive'|'outline'|'secondary'|'ghost'|'link' */
public string $variant = 'default',
/** @var 'xs'|'sm'|'default'|'lg'|'icon-xs'|'icon-sm'|'icon'|'icon-lg' */
public string $size = 'default',
) {}
}This is the same union form PHPStan/Psalm already understand for static analysis, so the docblock earns its keep in two places at once. No separate manifest to keep in sync.
B) Extend staticStrings with a Blade-attribute condition
Mirror the existing helper/method conditions. Something like:
{
"complete": "staticStrings",
"condition": [
{ "bladeComponent": "hw:button", "attribute": "variant" }
],
"options": {
"strings": ["default", "destructive", "outline", "secondary", "ghost", "link"]
}
}Packages ship this in their generated ide.json (I already generate my via an artisan command). Zero magic on the plugin side beyond the new condition shape.
Ideally both are supported: (B) as the default for typed component authors, (A) as an escape hatch when values are dynamic or when maintainers prefer a JSON-driven source.
Cheers!
Feature Description
Summary
Laravel Idea already autocompletes the names of props on custom Blade components (via ide.json → blade.components). It also already supports value autocompletion for PHP helpers and methods through
completions[].condition + staticStrings.What's missing is the natural bridge between the two: value autocompletion for Blade component attributes. For UI packages that follow the shadcn/Radix vocabulary (variant, size, tone, color, side, align…), this is the single most repetitive typing spot in a template.
Motivating example
variant on
<hw:button>accepts exactlydefault | destructive | outline | secondary | ghost | link. size acceptsxs | sm | default | lg | icon-xs | icon-sm | icon | icon-lg. Today the developer has to remember or look up these lists — the plugin has no way to surface them.The same pattern repeats across every component library in the ecosystem: Flux, Filament, MaryUI, TallStack UI, laravel-hotwire, and any shadcn-inspired preset.
Proposal
Two forms, in order of preference:
A) Infer from PHPDoc literal-string unions on promoted constructor props (preferred)
Laravel Idea already reads component constructors for prop names. Reading a literal-string union from the declared type would make the plugin infer allowed values with no ide.json involvement:
This is the same union form PHPStan/Psalm already understand for static analysis, so the docblock earns its keep in two places at once. No separate manifest to keep in sync.
B) Extend staticStrings with a Blade-attribute condition
Mirror the existing helper/method conditions. Something like:
{ "complete": "staticStrings", "condition": [ { "bladeComponent": "hw:button", "attribute": "variant" } ], "options": { "strings": ["default", "destructive", "outline", "secondary", "ghost", "link"] } }Packages ship this in their generated ide.json (I already generate my via an artisan command). Zero magic on the plugin side beyond the new condition shape.
Ideally both are supported: (B) as the default for typed component authors, (A) as an escape hatch when values are dynamic or when maintainers prefer a JSON-driven source.
Cheers!