Json Key Value Store Laravel Package

Product Decisions This Supports

• Reliability of feature/data deletion: The fix ensuring delete() operations persist after reopening a store directly supports features where users or systems expect removed keys to stay removed—settings, local state, feature flags, cached metadata, or lightweight configuration.
• Build vs. buy/adopt: If the product needs a simple file-backed key-value store with Laravel/PHP integration, this package can replace a custom JSON/file persistence layer. The recent exception and lock-related hardening reduces the hidden maintenance cost of a homegrown store.
• Operational diagnosability: Clear exceptions for file-open, missing-directory, JSON encoding, compression, and lock failures make failure modes easier to surface in logs, health checks, and support workflows.
• Roadmap compatibility: Testing PHP 7.1 through PHP 8.5 without raising the runtime minimum lowers upgrade friction for legacy apps while preserving a path to newer PHP versions.
• Use cases to prioritize: local application settings, small persistent caches, file-backed feature toggles, CLI/tool state, and single-node Laravel apps where a database table would be overkill.
• Use cases to avoid: multi-node write-heavy state, systems requiring transactional guarantees, auditability, schema/query capability, or a system of record.

When to Consider This Package

Consider adoption when:

• The product needs a small, persistent, file-backed key-value store inside a Laravel/PHP application.
• The team wants Laravel-native integration and does not want to build JSON read/write, locking, and compression handling from scratch.
• Deletion semantics matter and must survive store reopen—now explicitly addressed by v4.0.1.
• The deployment environment has reliable local disk and a single writer or acceptable lock-based concurrency.
• The application must support older PHP versions such as PHP 7.1 while preparing for PHP 8.5. Treat this as compatibility, not a security endorsement; PHP 7.1 is end-of-life.
• The team values explicit failure modes over silent corruption or ambiguous file errors.

Look elsewhere when:

• The data is business-critical or requires ACID transactions, relational queries, or multi-node consistency.
• The app runs on ephemeral containers, read-only filesystems, or shared network storage without validated locking behavior.
• The product needs encryption at rest, access control, audit trails, or regulatory retention controls beyond filesystem permissions.
• Write volume is high or concurrent writes are common; a database, Redis, or managed cache is safer.
• The team cannot own filesystem permissions, backup, and recovery procedures.

How to Pitch It (Stakeholders)

Executive summary: This package provides a lightweight, file-backed persistence layer for Laravel/PHP applications. The v4.0.1 release is a stability patch: it fixes deletion persistence so removed keys stay removed after reopening a store, adds clearer exceptions for common file and serialization failures, and modernizes CI while retaining broad PHP compatibility from 7.1 to 8.5. It is a low-risk upgrade for existing users and a reasonable adopt/buy option for small, single-node persistence needs—but it should not replace a database or distributed cache for critical, high-concurrency, or transactional data.

Engineering summary: v4.0.1 addresses a meaningful correctness issue in delete semantics, improves failure observability, and moves CI to GitHub Actions. No breaking changes are indicated in this patch. Before adoption, validate filesystem permissions, atomic write/lock behavior in the target deployment, backup/restore for the store files, and a plan to move off EOL PHP 7.1. If already used, upgrade and add a regression test covering delete-then-reopen behavior.