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

Categorizable Laravel Package

unisharp/categorizable

A Laravel package for adding polymorphic categories to Eloquent models. Attach and detach categories, organize them hierarchically, and query models by category with simple traits and scopes.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Framework upgrade / lifecycle gating. The only substantive content in 1.3.2 is a widened compatibility matrix (support laravel 6). For a PM, that is a decision input, not a feature: it determines whether this package can remain in (or enter) the dependency tree while the product sits on Laravel 6. Track it as a compatibility line item in upgrade planning, not as roadmap value.
  • Build vs. buy. A patch-level release that only adds framework support is a maintenance signal, not a capability signal. It tells you the package is being kept alive against newer framework versions, but says nothing about whether the maintainers are still investing in the problem domain. Do not use it to justify adoption on its own.
  • Dependency risk / roadmap exposure. The version number (1.3.2) plus a compatibility-only changelog is the classic profile of a package in low-velocity maintenance mode. That is a legitimate input to a "keep, replace, or vendor/fork" decision, and it should be logged as a risk on the roadmap rather than resolved by this release.
  • Use cases. This release supplies no new use cases, so it cannot expand the product surface. If the package is already in use, 1.3.2 is a low-friction upgrade; if it is not, nothing here creates a new reason to adopt.

When to Consider This Package

Adopt or retain when:

  • The team is on Laravel 6 (or another version inside the package's declared support range) and needs the capability the package provides rather than building it.
  • The upgrade from the previous pinned version is a bounded, testable change — patch-level semver implies no expected API breakage, so the cost is a composer update plus a regression run.
  • The alternative is in-house code that duplicates the package's job; a working, framework-compatible dependency usually beats a homegrown one for non-differentiating functionality.

Look elsewhere, or escalate before adopting, when:

  • You are on a current Laravel release. "Support laravel 6" implies Laravel 7+ is not covered. Treat that as a hard blocker for modern stacks, not a nice-to-have.
  • Timeliness matters. Laravel 6 shipped in 2019 and is well past its support window. A release note headlining Laravel 6 support is itself evidence the package's most recent work is years old — verify the actual release date and commit history before assuming active maintenance. If 1.3.2 is genuinely the latest release, plan for a fork or a replacement.
  • You need security responsiveness or a support contract. A project that adds framework compatibility without other changelog entries rarely has the cadence to ship urgent fixes. Confirm issue-response times and CVE history.
  • A maintained alternative exists. Prefer the actively developed package unless switching costs dominate.

Note on confidence: this assessment rests on a single one-line changelog with no package metadata (no README, composer constraints, test coverage, or release dates). Treat the maintenance-velocity read as a hypothesis to confirm with a fifteen-minute repo check before it drives a build-vs-buy call.

How to Pitch It (Stakeholders)

For executives: 1.3.2 is a maintenance release — it adds Laravel 6 to the supported framework versions and introduces no new capability. There is no new value to sell and no migration cost to fund. The real message is a risk signal: the package's newest release appears to target a 2019-era framework, which suggests the project is not actively developed. Recommend we treat it as a stable, low-velocity dependency and set a review checkpoint rather than investing further in it.

For engineering: Patch-level compatibility bump; expect no public API change. Verify the composer.json framework constraints actually permit Laravel 6 and confirm whether any constraints were loosened or tightened, run the existing test suite, and check the release date and commit cadence while you are in the repo. Report back on whether the package supports anything past Laravel 6 — that single fact determines whether this is a routine upgrade or a forced replacement.

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.
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
glavweb/extra-bundle
glavweb/api-bundle
glavweb/admin-bundle