- How do I install johngrogg/ics-parser in a Laravel application?
- Install it with Composer using johngrogg/ics-parser:^3; note the vendor is johngrogg, not the GitHub organisation u01jmg3, which is a common copy and paste mistake. There is no service provider, facade, config file or migration to publish, so nothing registers automatically. In Laravel you instantiate the parser inside an application-owned adapter class and bind that adapter in a service provider.
- Does johngrogg/ics-parser support Laravel 10, 11 and modern PHP versions?
- The package has no framework constraints at all, so it does not block Laravel upgrades and framework-upgrade risk is close to zero. It requires PHP 5.6.40 or higher, and the v3 branch supports PHP 8 alongside PHP 7.4 and PHP 5.6. Confirm that your exact PHP minor is in the tested matrix rather than relying on the word supported, because the compatibility range is broad and CI coverage may be narrower.
- Can johngrogg/ics-parser generate or write .ics files?
- No, it is a read-only parser: it takes a valid .ics, .ical or .ifb file and returns associative arrays for the calendar and its events. For outbound publishing pair it with a generator such as spatie/icalendar-generator or eluceo/ical. It is also not a CalDAV client, so two-way synchronisation is out of scope and belongs to a different library.
- How does johngrogg/ics-parser handle recurring events and RRULE expansion?
- Recurrence is the highest-risk area, so verify it empirically with your own fixtures instead of assuming full RFC 5545 behaviour. The README explicitly notes the parser is limited to relative date formats, which can inhibit processing of complex recurrence rule parts such as BYDAY combined with BYSETPOS. Check whether RRULE expands into discrete instances in your use case and whether EXDATE and RECURRENCE-ID overrides are honoured. Also measure the cost of an unbounded FREQ=DAILY rule before trusting it in production.
- How are time zones and DST handled by johngrogg/ics-parser?
- The parser accepts IANA, Unicode CLDR and Windows time zone identifiers and injects dtstart_tz and dtend_tz keys so you can read start and end values with time zone data applied. Where possible it returns real DateTime objects rather than raw strings. VTIMEZONE blocks, IANA resolution and DST boundary cases still need explicit test coverage, particularly around transition dates and Windows zone names. Normalise to UTC in your adapter so the rest of the application never deals with naive local times.
- What does johngrogg/ics-parser actually return for events, all-day entries and properties?
- Each key and value pair from the iCal file becomes an associative array for the calendar and for every event, and the parser also injects special property_array entries that further resolve a value, for example dtstart_array with its TZID. Date and time values are DateTime objects where possible, with the time zone applied variants exposed as dtstart_tz and dtend_tz. Representation of all-day VALUE=DATE entries versus timed and floating times should be confirmed against fixtures. Treat the raw arrays as an integration boundary and map them into your own DTOs immediately.
- Is johngrogg/ics-parser safe and fast enough for large or untrusted .ics feeds?
- The whole file is loaded and parsed in-process, so memory is your denial-of-service vector when feeds are externally controlled. Oversized files, pathological line folding, non-UTF-8 encodings and malformed datetimes are all realistic inputs you must defend against. Benchmark a representative feed, such as 5 MB and 10,000 events, before committing, and impose file size limits, timeouts and caching around the call. Parsing untrusted calendar data should never happen unbounded inside a web request.
- What is the best way to structure johngrogg/ics-parser in a Laravel codebase?
- Confine the vendor class to a single adapter, for example app/Services/Calendar/IcsParserAdapter implementing your own CalendarParserInterface, and bind it in a service provider. Normalise the parser output at that boundary into DTOs such as CalendarEvent, EventUid and RecurrenceSpec so raw parser arrays never reach your domain layer or database schema. Fit it to the read path only: fetch a .ics from a URL or storage disk, parse it, then map to Eloquent models. That seam is the difference between a two-day swap and a two-week migration later.
- How should I test .ics parsing in a Laravel project?
- Write fixture-driven contract tests against real feeds: Google, Outlook, property or booking platforms, DST transition cases and deliberately malformed inputs. If you are replacing ad-hoc date or string parsing, introduce the adapter alongside the existing code and run both paths in shadow mode against production feeds, diffing outputs per source before cutting over. Keep those tests tied to the interface rather than the vendor class so an eventual swap is verifiable. Run the package test suite with composer test as a baseline sanity check.
- Is johngrogg/ics-parser actively maintained, and what are the alternatives?
- It is actively released with a broad PHP 5.6 to 8+ matrix, but continuity rests on a single maintainer, so treat the bus factor as real and pin the version. Adoption signals are thin, with roughly 482 stars and a reported zero dependents, so treat it as unproven at scale rather than safe by default. Validate the release cadence on Packagist directly, because the release metadata includes an anomalous future date. Plan the exit ramp as a realistic eventuality: sabre/vobject offers broader RFC coverage plus CalDAV and vCard support and can sit behind the same interface.