Php Ext Xlswriter Ide Helper Laravel Package

Getting Started

This package is not a library you call at runtime — it is a set of PHP stub/PHPDoc declarations for the Vtiful\Kernel\Excel class and related types exposed by the native ext-xlswriter extension. Its only job is to make your IDE stop underlining every $excel->header(...) call in red.

Minimal setup:

# 1. Install the actual extension the code will run against
pecl install xlswriter
# or: apt/brew/pie-install depending on your platform, then enable extension=xlswriter.so

# 2. Add the IDE helper as a dev-only dependency
composer require --dev viest/php-ext-xlswriter-ide-helper

Verify the extension is genuinely loaded before trusting anything:

php -m | grep xlswriter
php -r "var_dump(class_exists('Vtiful\Kernel\Excel'));"

Then have your editor reindex (PhpStorm: File → Invalidate Caches, or just "Reload from Disk" on the vendor folder). VS Code with Intelephense picks it up via vendor/ automatically.

First use case: open any file that does use Vtiful\Kernel\Excel; and start typing $excel-> — you should see fileName, header, data, output, constMemory, insertText, openFile, openSheet, nextRow, autoSize, etc. as real method signatures rather than "method not found".

Implementation Patterns

Dev-only dependency, production-free. Always --dev. The package adds zero runtime weight and should never appear in require. In CI you can install it via composer install (dev deps included) so static analysers see the stubs too.

Align the stub with the installed extension version. The helper's classes mirror a specific release of ext-xlswriter. If your extension is newer than the stubs, method signatures may be missing or subtly different (e.g. argument order on insertDate, new header options). When you upgrade the extension, bump the helper and reindex. Check the stub package's composer.json/release tags against php -r "echo phpversion('xlswriter');".

Pair it with an export/import action. The stubs exist so that the fluent chains in your export actions autocomplete correctly. A typical write path looks like:

$excel = new Excel(['path' => $exportDir]);
$path = $excel
    ->fileName('orders.xlsx', 'Orders')
    ->header(['Order No', 'Customer', 'Total'])
    ->data($rows)
    ->output();

…and now your IDE will correctly hint header(array $header): static, data(array $rows): static, and output(): string — so you don't second-guess whether output() returns a path or a bool.

Large exports / imports rely on correct signatures too. Streaming patterns (constMemory() + chunkById, or openFile()->openSheet()->nextRow() loops) depend heavily on knowing the exact shape of the return value:

$reader = (new Excel(['path' => $dir]))->openFile($file)->openSheet();
while ($row = $reader->nextRow()) { /* ... */ }

With the IDE helper installed, nextRow() resolves to array|false (or similar) instead of "undefined method", which is exactly the friction this package removes.

Static analysis integration. Because the package ships plain PHP stubs under vendor/, PHPStan and Psalm will resolve Vtiful\Kernel\Excel without needing a custom scanFiles entry — provided your phpstan.neon includes vendor/ (the default with Larastan/normal config). This lets you keep level 5+ rules on export services.

Framework wrappers. If you have a PdfExport/ExcelExport wrapper around Vtiful\Kernel\Excel, the stub propagates through return types — annotate your wrapper with @return \Vtiful\Kernel\Excel and IDE/static analysis will follow it downstream.

Gotchas and Tips

It does nothing without the extension. If ext-xlswriter is not installed, your code new Excel([...]) will fatal at runtime (Class "Vtiful\Kernel\Excel" not found) even though the IDE happily autocompletes. The helper only teaches the IDE what would be there. Always gate on extension_loaded('xlswriter') in setup docs/environments.

Version drift between stubs and extension is the #1 trap. Stub packages like this are updated sporadically (this one has low star count, 0 dependents). If your extension release added a method the stubs don't know, you get a false "undefined method" — or worse, wrong argument hints. Pin the helper to ^x.y that matches your extension build, and if a signature looks wrong, treat the extension's own reflection as ground truth:

$ref = new ReflectionClass(\Vtiful\Kernel\Excel::class);
foreach ($ref->getMethods() as $m) { echo $m->getName(), "\n"; }

Never ship it to prod. Add it to require-dev and exclude from any --no-dev production build (which Composer does automatically). In Docker multi-stage builds running composer install --no-dev, this package disappears — that's correct and intended.

IDE caching. PhpStorm in particular likes to hold onto stale class indexes. After installing/upgrading, use File → Invalidate Caches / Restart, or at minimum Reload from Disk on the vendor tree. Without that, the stubs may appear in vendor/ but stay "not found" from your code's perspective.

Static analysis vs. runtime confusion. PHPStan will accept $excel->header([...]) cleanly thanks to the stubs — but that is not proof the extension is installed or the version is compatible. Keep a smoke test in your suite that actually constructs an Excel object and writes a tiny file. Stubs make bad code look good to the analyser.

Extensibility: write your own stub if needed. If you need a class the helper doesn't cover (older \Vtiful\Kernel\Format, Chart, or a new Cursor API), you can add a short @method PHPDoc block on your own wrapper class, or drop a stub into your project's stubs/ directory and configure PHPStan's stubFiles / IDE include paths — cheaper than waiting for the upstream stub package to catch up.

Unmaintained risk. 16 stars, 0 dependents means low community momentum. If the package rots against a future extension version, the safe fallback is a hand-written _ide_helper_xlswriter.php in the project root declaring the handful of methods you actually use. Don't let a dev-only convenience become a blocker for extension upgrades.