Array Column Laravel Package

Product Decisions This Supports

• PHP version support matrix / deprecation roadmap. This package exists solely to backfill array_column() for PHP < 5.5. Its presence in a codebase is a direct signal that a product (or one of its transitive dependencies) still supports an end-of-life runtime. That makes it a useful data point when deciding whether to keep, freeze, or retire legacy PHP support.
• Legacy maintenance vs. modernization budget. If a product line still ships on PHP 5.3/5.4 (common in older WordPress plugins, internal tools, and long-lived enterprise apps), this is a near-zero-cost way to unblock a migration spike without rewriting array-handling code. The decision it supports is "patch in place" vs. "invest in an upgrade."
• Build vs. buy (vs. copy). array_column() polyfills are roughly 15–30 lines of code. The decision is not really build-vs-buy—it's whether to carry a third-party dependency for something you could vendor inline, and whether an archived dependency is acceptable under your supply-chain policy.
• Dependency hygiene and audit findings. Because the package is archived and last released in 2015, its appearance in an SBOM or dependency scan triggers a "what is this and why do we have it?" review. That's a legitimate forcing function for cleaning up stale transitive dependencies.
• Tooling and code-standard decisions. If you maintain an internal library or shared package, this informs whether you target broad PHP compatibility (polyfills) or require modern PHP and drop the shim.
• Not a lever for new product features. There is no user-facing capability here. Do not let it appear on a roadmap as an investment item; it is purely a compatibility tax.

When to Consider This Package

Consider it only when:

• You must execute on PHP < 5.5 and need array_column() behavior, and you cannot bump the runtime in the current release cycle.
• You're doing a short-lived compatibility bridge during a migration and want a known, MIT-licensed shim rather than hand-rolling one.
• Your tooling requires an explicit dependency rather than inline code (e.g., strict dependency manifests, reproducible builds).

Look elsewhere when:

• You're on PHP 5.5+. array_column() is native. The package adds nothing but dependency risk.
• Any new project. Archived since 2015, no maintenance, no security response path. Even where the risk is tiny, the policy cost outweighs the benefit.
• A maintained polyfill is available. symfony/polyfill-php55 provides array_column() and is actively maintained—this is the defensible substitute in almost every case where the need is real.
• You can bump PHP instead. The correct fix is upgrading the runtime, not carrying a decade-old shim. Treat this package as evidence for the upgrade, not a substitute for it.
• Your supply-chain policy prohibits archived/unmaintained dependencies. Most modern orgs do; respect that rather than making a one-off exception for a trivial helper.
• You're already writing compatibility code. Inline the function under your own namespace and remove the dependency entirely.

How to Pitch It (Stakeholders)

To executives: This is a tiny, archived compatibility helper for a PHP feature that has been built into the language since mid-2013. It is not a strategic dependency, it delivers no user-facing value, and it should not be adopted for anything new. Its only real value to us is as evidence: wherever it appears, we are still paying to support an end-of-life runtime. I recommend we treat it as a signal to fund PHP upgrades and shrink our legacy support surface, not as a component to standardize on. If a team genuinely needs the functionality on an old runtime, we point them to the maintained Symfony polyfill instead.

To engineering: The package is ~20 lines of MIT-licensed code that backfills array_column() for PHP < 5.5. It was last released in March 2015 and is archived—no fixes, no security response. If you encounter it: (1) check whether the PHP floor can simply be raised, which removes the dependency outright; (2) if not, swap to symfony/polyfill-php55, which is maintained and covers the same gap; (3) if you only need it in one place, vendor the function directly and drop the dependency. Do not add it to new work, and flag it in upgrade planning as a legacy-compatibility marker rather than something to preserve.