File Image Laravel Package

Product Decisions This Supports

• Derived-image strategy for user content. This package answers a narrow but recurring product question: "when a user uploads an image, how do we produce the smaller versions we actually render?" It supports an on-demand variant model — store the original once, request a constrained render (max width or max height, optionally square-cropped) at display time — as opposed to an eager fan-out model that pre-generates and stores every size at upload. That choice has downstream consequences for storage cost, backfill/reprocessing effort when a design changes, and how quickly you can ship a new thumbnail size.
• Intent-based sizing contracts with design/frontend. The API takes a maximum bound rather than exact pixel dimensions. That is a product-friendly contract: specs like "hero images never exceed 1200px on the long edge" or "avatars are square-cropped" map directly onto a request, and the frontend does not need to hardcode a fixed ladder of variants. It makes responsive-image work cheaper to iterate on, because changing a breakpoint is a caller change, not a migration.
• Build vs. buy for the image pipeline. The realistic decision here is not "adopt vs. don't" in the abstract — it is whether the image pipeline is core or commodity. For most products it is commodity, so the decision reduces to picking the thinnest thing that works and isolating it. This package is a candidate only inside the rekalogika/file + Doctrine attachment ecosystem; outside it, the build cost of reproducing a max-dimension + square-crop filter on top of an established imaging library is a few days of engineering.
• Roadmap sequencing. If variant generation is unowned today, this is a low-effort way to unblock a thumbnail/avatar feature without standing up a resize service. It should be scoped as a tactical enabler, not the foundation of a long-term media platform — the absence of format negotiation (WebP/AVIF), focal-point cropping, and cache invalidation means a serious media roadmap will outgrow it.
• Vendor and maintenance posture. The repository is a read-only subtree split of the upstream rekalogika/file monorepo. That matters for procurement: patches and issues belong upstream, so any fork your team maintains is a fork of the monorepo, not this repo. Adopting it means accepting a single-maintainer dependency in a code path users see.

When to Consider This Package

Consider it when all of the following hold:

• You are already running rekalogika/file with Doctrine entities for attachments. This package's entire value is that it plugs into that file abstraction; the resize logic itself is not the differentiator.
• Your image requirements are genuinely simple: constrain to a maximum width or height, and optionally square-crop. No watermarks, no format conversion, no focal-point or smart cropping, no compositing, no per-variant quality tuning.
• You want a permissive, minimal, PHP-native dependency (MIT, small surface) rather than introducing a service or a heavier imaging stack.
• You accept that you own the surrounding machinery — where derived files are stored, how they are cached, when they are invalidated, and how they are served — because this package produces a filter result, not a caching or delivery layer.
• Low blast radius is acceptable. If the dependency stalls, swapping it out should be a contained change behind your own interface.

Look elsewhere when any of the following hold:

• Strong adoption signal is required. One star and zero dependents is not a quality verdict, but it is a maintenance-risk signal. For a core, user-visible path (every profile page, every listing), prefer something with a track record, or budget explicitly for the possibility that you become the maintainer.
• You need modern delivery formats. Responsive srcset, WebP/AVIF negotiation, and Accept-header-driven format selection are table stakes for image performance. This package does not address them.
• You need a real transformation pipeline. intervention/image, spatie/image, glide, or liip/imagine-bundle cover cropping strategies, filters, and format control with far broader usage. For scale and offload, imgproxy, Cloudinary, or imgix move resizing off your application servers entirely — usually the right answer once image traffic is material.
• You are not on rekalogika/file. Adopting a file-abstraction library and its filter plugin to get resizing inverts the build/buy calculus; a standalone imaging library is the shorter path.
• You require vendor support, SLAs, or security response commitments. None of those exist here.

How to Pitch It (Stakeholders)

For executives (one paragraph): Image resizing is a commodity capability, not a differentiator, so the goal is to spend as little as possible on it while keeping the option to change approach later. This package is a small, MIT-licensed helper that produces resized copies of uploaded images inside an existing PHP file-handling stack. It would let us ship thumbnail and avatar features quickly at effectively zero licensing cost. The caveats are honest ones: it is maintained by a single author, has essentially no adoption, and does not handle modern image formats or caching. My recommendation is to treat it as a tactical utility — use it to unblock near-term work only if we are already on the underlying file library, and put it behind our own image-service interface so that replacing it with a hosted resizing service later is a contained change rather than a rewrite. I would not build a long-term media strategy on it.

For engineering: The API is deliberately narrow — caller supplies a maximum width or height plus a square-crop flag, and gets a filtered result. That intent-based shape is the good part: it keeps sizing policy at the call site and out of stored data. The gaps you will have to fill are the ones that actually cost money: persistence and lifecycle of derived files, cache keys and invalidation when the source or the requested bounds change, and delivery (CDN, srcset, format negotiation). Note the repository is a read-only split of the upstream monorepo, so upstream is where issues and patches go. Recommended integration: define a small ImageTransformer port in our domain, implement it with this package, and keep the option of an imgproxy/Cloudinary adapter behind the same port. That costs an interface and buys us a clean exit.