- How do I install viest/xlswriter for a Laravel application?
- It is installed as a PECL extension, not with Composer. Run pecl install xlswriter (or download a prebuilt binary on Windows), then enable it with extension=xlswriter.so in the relevant php.ini. In Docker, build libxlsxwriter and the extension in a build stage of your base image so every PHP container ships with it. Pin the extension version and confirm it loads before your application boots.
- Can I just run composer require viest/xlswriter?
- No. viest/xlswriter is a PHP C extension distributed through PECL and source builds, not a Composer library, so there is nothing for Composer to autoload. That means standard dependency tooling and SBOM scanners will not see it at all, which is why you should track it explicitly in your base-image Dockerfile and infrastructure dependency register. Treat it like pdo_mysql or gd: a host capability rather than a declared package.
- Can xlswriter read or modify existing XLSX files?
- No, it is write-only by design. It wraps libxlsxwriter to create new XLSX files, and there is no reader included, so it cannot open, amend or round-trip an existing workbook. If your product needs to read or edit user-uploaded spreadsheets, keep a pure-PHP reader such as PhpSpreadsheet for that path and use xlswriter only for generating new exports.
- How does xlswriter keep memory low on very large Excel exports?
- Because the writing is done in C and supports a disk-cache option, large exports are bounded by temporary disk space instead of PHP memory. That is the main reason to choose it over pure-PHP writers for nightly reports, statements and bulk extracts with hundreds of thousands of rows. Point the temp directory at fast local scratch storage, stream the finished file to S3 or your download response, and clean up afterwards. Measure your p95 row count and export size so you can size the scratch volume correctly.
- Which PHP and Laravel versions does the xlswriter extension support?
- The extension is not tied to a Laravel version at all, since Laravel only sees the Vtiful\Kernel\Excel class it exposes. What matters is the PHP build it was compiled against: it must be rebuilt for every PHP minor upgrade, and Alpine/musl and Windows environments each have their own quirks. Check the repository for currently supported PHP versions and add an extension_loaded('xlswriter') assertion to CI so a base-image bump cannot silently remove it.
- Why am I getting Class "Vtiful\Kernel\Excel" not found in Laravel?
- That fatal error means the extension is not installed or not enabled for the PHP binary your application is running, and there is no Composer autoload fallback to save you. Confirm with php -m | grep xlswriter and check that the php.ini being loaded by your FPM or CLI process includes the extension. In containers, verify the extension is present in the exact image and PHP version serving the request, not just on your laptop.
- Can I use xlswriter on Laravel Vapor, AWS Lambda or shared hosting?
- Generally no. It requires you to control the PHP build, so serverless-first platforms and managed shared hosting where you cannot install a PECL extension are poor fits. It works well on containerised infrastructure with a queue worker tier, exporting to local scratch disk and then uploading to object storage. If you must support those targets, keep a pure-PHP export adapter behind an interface and select it per environment.
- How do I test a Laravel app that depends on xlswriter in CI?
- Introduce a narrow seam rather than calling the extension directly: an exporter interface with export(ReportDefinition $def): string returning a temp path, plus two implementations. Use a pure-PHP exporter for developer laptops and CI runners without the extension, and the xlswriter implementation in production containers. Add a CI job that asserts extension_loaded('xlswriter') on the production image and runs a small smoke export so build-time breakage is caught before deploy. Keep a shared test suite that runs against both adapters to prove their output is behaviourally identical.
- How does xlswriter compare to PhpSpreadsheet for large Excel exports?
- For write-only, high-volume generation, xlswriter is dramatically faster and lighter because it is C built on libxlsxwriter with optional disk caching, and it natively supports formulas, charts, images, formatting, conditional formatting and data validation. PhpSpreadsheet is pure PHP with no host requirements and can also read and modify workbooks, but it costs far more memory and CPU at scale. Many teams run both: xlswriter for bulk exports, PhpSpreadsheet for imports and small ad hoc edits. Do not replace PhpSpreadsheet wholesale on day one; route individual export types through a config flag instead.
- What are the production risks of running a C extension like xlswriter?
- The biggest availability risk is drift: the extension has to be recompiled for every PHP minor upgrade, so a base-image bump can break exports at runtime unless you assert its presence in CI. The biggest blast-radius risk is that a segfault inside the extension kills the whole PHP-FPM worker rather than one request, which can surface as intermittent 502s under load instead of a clean exception. Mitigate by pinning versions, validating and sanitising user-supplied strings before writing them (to avoid formula and CSV injection), and running exports on dedicated queue workers. The BSD-2-Clause licence itself is permissive and unproblematic, but the small maintainer group and historically Chinese-language documentation are worth noting in your risk register.