Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Baseline Laravel Package

limenet/laravel-baseline

A Laravel package that provides a reusable baseline for new projects, bundling sensible defaults, common configuration, and setup conventions so you can start from a consistent foundation. It reduces repetitive setup work and keeps applications aligned with limenet's conventions.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

limenet/laravel-baseline is an opinionated baseline/guardrail package for Laravel projects: it ships a set of named checks that assert a project's tooling configuration meets a house standard (Rector, PHPStan, and related PHP tooling). v2.18.0 is a purely additive minor release under the php feature scope, introducing two new checks: hasRectorConfigWithCache and phpstanHasTmpDir.

  • Architecture fit: Strong for teams standardising CI hygiene. The package is a dev-only dependency that composes discrete, individually addressable checks, so adopting two new ones requires no application-code changes. It sits alongside Rector/PHPStan rather than replacing them — it validates their configuration, not their output.
  • Integration feasibility: Low effort. Bump the dev dependency to ^2.18, expose the new checks in the baseline configuration, and let the existing CI job exercise them. No runtime surface, no production coupling.
  • Technical risk: Low. Minor-version, additive, no deprecations or removals signalled. The main risk is behavioural rather than structural: if the new checks are enabled by default or inherited by a shared baseline preset, previously green pipelines can start failing on repos whose Rector config lacks caching or whose PHPStan config lacks a tmpDir.
  • Key questions:
    • Are the new checks opt-in, or do they activate automatically for consumers of the default baseline?
    • Do they hard-require Rector/PHPStan to be installed, or do they no-op gracefully when those tools are absent?
    • What is the expected config shape — withCache() in rector.php, and tmpDir under parameters in phpstan.neon — and is the check tolerant of custom config paths?
    • Any minimum supported Rector/PHPStan/PHP versions implied by the new checks?

Integration Approach

  • Stack fit: Laravel 10/11/12-era PHP projects already running Rector and PHPStan in CI. Teams not using those tools get no value from these two checks and can ignore the release.
  • Migration path: Semver-minor bump in composer.json (require-dev), composer update limenet/laravel-baseline, then run the baseline suite locally before pushing. Remediation is configuration-only: add caching to the Rector config and set a tmpDir for PHPStan.
  • Compatibility: Backwards compatible by declaration. The practical compatibility gate is the Rector/PHPStan versions in each consuming repo, not the baseline package itself — worth confirming the checks don't assume a config schema newer than what teams run.
  • Sequencing:
    1. Bump the dependency in a single low-traffic repo first.
    2. Run the suite and catalogue failures attributable to the two new checks.
    3. Decide per-repo whether to satisfy the check or explicitly disable it.
    4. Roll the bump across remaining repos once the failure profile is known.
    5. Only then enable the new checks in the shared baseline preset, if that is the intended end state.

Operational Impact

  • Maintenance: Near-zero. Dev dependency, vendor-maintained, small surface. Pin the minor and let patch releases flow; review minor bumps for new checks that could flip CI red.
  • Support: Upstream GitHub project with conventional-commit changelog and linked commits; no commercial support path. Escalation for a bad check is "disable it and wait for a patch."
  • Scaling: Negligible cost. The checks are static config assertions and add seconds to an existing CI job; no impact on request-path performance or infrastructure footprint.
  • Failure modes:
    • Pipeline breakage on upgrade — the dominant risk; a new check fails repos that were previously compliant.
    • False positives on nonstandard layouts — configs at custom paths or with equivalent-but-different cache settings may be flagged.
    • Sandbox friction — a PHPStan tmpDir requirement can collide with read-only or ephemeral CI filesystems; teams may need to point tmpDir at a writable path.
    • Silent drift — if checks are disabled ad hoc to unblock pipelines, the baseline loses its value without anyone noticing.
  • Ramp-up: Trivial for anyone who has edited rector.php or phpstan.neon. Budget a short spike to establish the team convention for tmpDir placement and Rector cache enablement, then document it once so subsequent repos are copy-paste.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle