Time Window Bundle Laravel Package

Technical Evaluation

Architecture fit — pattern-fit, not package-fit. This is a Symfony bundle, not a Laravel package. Laravel consumes individual Symfony components, not bundles — there is no Kernel, no bundle registration, no DI extension loading. The package will install via Composer but will never boot in a Laravel app, so the flag service, config tree, and any shipped helpers are unreachable. The domain concept — a time-bounded feature flag — is framework-agnostic and small enough to matter to the product roadmap, so the idea transfers cleanly; the artifact does not.

Integration feasibility — bounded, not a migration. The underlying logic is a thin predicate: given a flag name and a config-declared window, evaluate now() against the boundary. Reimplementing it in a Laravel service provider plus a config file is a one-to-two day effort, not a project. The honest framing for planning is "adopt the pattern; do not add the dependency."

Technical risk — high, driven almost entirely by maturity signals. Zero stars, zero dependents, and a score of 0 mean no production usage trail, no issue history, and no downstream projects to infer API stability from. This is a personal bundle, and that matters for the product decision:

• Bus factor of one. No second maintainer, no visible release cadence.
• Unverifiable API stability. With no dependents, breaking changes cost the author nothing.
• Supply-chain surface with no return. Adding a transitive dependency to obtain roughly fifty lines of date comparison is a bad trade, especially for a capability we may want to extend (segment targeting, overrides, audit).
• Semantics risk. Time-window logic is deceptively hard: timezone handling (app vs. UTC vs. per-flag), DST transitions inside a window, inclusive vs. exclusive boundaries, and clock skew across horizontally scaled instances. A zero-adoption package offers no evidence these were considered, and a bug here surfaces as a flag flipping on hours early or late.

Key questions to resolve before committing:

1. Does the bundle store flag state only in config, or does it persist to a database/cache? (Affects whether windows are changeable without a deploy.)
2. Are windows evaluated in app timezone, UTC, or per-flag — and how are DST boundaries handled?
3. Is evaluation per-request, or cached/precomputed? (Determines safety on a hot path.)
4. Does the config model support per-user or per-cohort targeting, or is it purely global time-based?
5. Who owns the maintainer relationship, and is there any intent to support ongoing maintenance?

Integration Approach

Stack fit — none, as delivered. Laravel's service container, config repository, and Blade surface have no bridge to Symfony bundle conventions. There is no supported path where this becomes a Laravel dependency in the normal composer require sense.

Recommended path: port the concept, not the code. Two viable options, in preference order:

1. Native Laravel implementation (recommended). A small internal package: config/feature-flags.php declaring windows per flag; a TimeWindow value object that evaluates boundaries with explicit timezone handling; a FeatureFlagService bound as a singleton; a Blade directive and a Feature::active('x') facade. Layer on Laravel Pennant if broader flag capability is wanted later — Pennant handles the flag plumbing, and we supply a time-window scope. This is the path if the requirement is durable.
2. Read the bundle as reference only. Skim its DependencyInjection/ and evaluator class to sanity-check our window semantics (boundary inclusivity, timezone resolution), then close the tab. No Composer entry, no LICENSE attribution burden, no upgrade obligation.

Compatibility. PHP version constraints must be checked even for reference reading — a bundle targeting an older Symfony LTS may carry deprecated date APIs. Nothing here should constrain our PHP or Laravel upgrade path, precisely because we are not depending on it.

Sequencing. (1) Confirm the actual product requirement — time-boxed rollout for a launch, or recurring schedule-based behavior. These want different designs and different config shapes. (2) Decide build-in-house vs. Pennant-plus-scope. (3) Build and unit-test the window evaluator with explicit coverage for DST transitions, midnight-crossing windows, and timezone offsets. (4) Wire into the flag check used by the target surface. (5) Ship behind a manual override so ops can force-enable or force-disable independent of the clock.

Operational Impact

Maintenance — we own it either way. Depending on this package does not transfer maintenance; it adds an obligation (tracking a stranger's commits) on top of code we would likely have written ourselves. In-house, the surface is small enough to be genuinely low-maintenance: one service, one config file, a handful of tests.

Support. No commercial support, no community, no documented upgrade guides. Internal-only expertise is required regardless of path. Budget for the owning team to be the sole escalation point, and document the timezone semantics because they will be the source of any incident.

Scaling. Negligible compute cost — a date comparison per check. The real scaling concern is consistency: with multiple app instances, every node must resolve "is it inside the window" identically. Pin the app timezone explicitly in config, never rely on the server's local clock, and keep the window definition in a single source of truth rather than per-node state.

Failure modes to design for:

• Clock/timezone misconfiguration — the classic failure: a flag flips on hours early or late, or not at all, because one environment runs UTC and another runs local time. Mitigate with an explicit timezone per flag and a boot-time assertion.
• No kill switch — a purely clock-driven flag cannot be turned off during an incident if the window says "on." Pair every time window with a manual override, and surface that override in the runbook.
• DST and boundary edge cases — a window that starts at 02:30 on a spring-forward day may not exist. Test it and define the behavior before launch.
• Stale config after deploy — if windows are config-driven, changing one requires a deploy. Acceptable for planned launches; unacceptable if the business expects to flip windows ad hoc. Decide this with product early.
• Silent expiry — a flag whose window has passed becomes permanently off and nobody notices the code path is now dead. Add logging when a flag is evaluated outside its window, and a review cadence to remove expired code paths.

Ramp-up. Low. A mid-level Laravel engineer unfamiliar with feature flags can own the in-house version within a day; the only non-obvious area is timezone and DST semantics, which is where review time should be concentrated. There is effectively zero ramp-up cost avoided by adopting the package, since its Symfony wiring is unusable and its logic must be understood anyway.

Bottom line for the TPM: this is not a dependency decision, it is a build decision. The package is a useful piece of prior art for a small, well-understood problem; adopt the pattern, implement natively in Laravel, and avoid the zero-adoption dependency. The product payoff — scheduling time-limited features without extra deploys, and forcing every temporary flag to carry its own expiry — is real and cheap to capture. The decision criteria to bring back are time-to-launch for scheduled features, the count of stale flags currently in production, and the cost of ownership for a vendored micro-dependency versus an internal primitive.