Laravel Linear Laravel Package

Product Decisions This Supports

• Build vs. buy for Linear integration. This package collapses "connect our Laravel app to Linear" from an internal project into a dependency. It is the deciding input for whether a Linear-linked feature ships this cycle or gets deferred.
• Feature shape: creating Linear issues from app events (exceptions, support submissions, ops alerts), attaching release/version context, and posting a human-readable message alongside the issue. The Message can now be null change (v1.4.1) matters here: callers can now omit a message body instead of passing a placeholder string, which removes a class of defensive wrapper code we would otherwise write and maintain.
• Data contract decision: if your product logic assumes every Linear issue/comment carries a message (search, routing, reporting, notification copy), a nullable message means you must decide what a "messageless" issue looks like in your workflows. Treat this as a product rule, not an implementation detail.
• Roadmap risk: the fix implies the payload model is loosely typed and evolving. Fine for creation-style use cases; a caution if you plan two-way sync, custom-field mapping, or cycle/roadmap management on top of it.
• Not a platform bet. The v1.4.1 diff is a Dependabot webpack bump plus one nullability PR — a maintenance-grade release with no breaking changes, no deprecations, and no new capability. It should not move roadmap priorities; it should reduce the perceived risk of adopting.

When to Consider This Package

Consider it when:

• You are on Laravel and have already standardized on Linear as the system of record for engineering work.
• You need straightforward outbound integration (create issue, post message) rather than a full bidirectional synchronization layer.
• You would rather take a Composer dependency than own a GraphQL client, auth handling, and retry logic.
• You can live with a thin maintainer footprint and pin your version.

Look elsewhere or build in-house when:

• You need real-time webhooks, complex custom-field mapping, or write-back status sync — verify current coverage explicitly before committing.
• You are not on Laravel, or you need vendor-backed SLAs and support.
• A single-maintainer project is a governance blocker for your team.

Adoption criteria and cautions for this release specifically:

• No breaking changes in 1.4.1. Upgrade from 1.4.0 is safe; behavior only widens (null accepted where a value was previously expected).
• Maturity signals are shallow but positive. Continuous dependency updates and a bug-fix PR indicate active maintenance; a two-item patch release indicates a small project. Assess bus factor accordingly.
• Dependency hygiene: a webpack bump inside a PHP package implies shipped front-end build tooling or compiled assets. Confirm whether those assets are served in production — if so, they are part of your supply-chain surface, not just dev tooling.
• Mitigation regardless of fit: pin to ^1.4, wrap the package behind a small internal adapter interface, and add a test that exercises the no-message path, since that path's behavior just changed.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that lets our Laravel services file work directly into Linear instead of relying on manual handoffs. The upgrade itself (v1.4.1) is a maintenance patch — no breaking changes, no migration cost, no new licensing or vendor commitment. It accelerates an engineering-ops integration; it is not an architectural commitment, and it is swappable.

To engineering: v1.4.1 accepts a null message, so callers no longer need to fabricate message text — remove any placeholder-string workarounds and cover the no-message case with a test. The webpack bump is dependency hardening; confirm nothing compiled is served in production. Version is pinned and the package sits behind our adapter, so a future upstream change or abandonment costs us a contained swap to direct GraphQL calls rather than a rewrite.