Ftp Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for FTP/SFTP integration work: This package remains a thin object-oriented wrapper over PHP's native ftp_* extension (connect, login, passive mode, upload/download, directory listing, chmod, delete). If a roadmap item is "let admins push/pull files to a partner's FTP server," the method list still gives a usable floor for sizing an in-house implementation — roughly a dozen methods.
• Scope definition for file-transfer features: Keep using the wrapper's method list as an acceptance-criteria checklist: connection lifecycle, authentication, passive/active mode, binary vs. ASCII transfers, recursive directory handling, error propagation. The gaps are unchanged and are where estimates go wrong: retries, resumable transfers, connection pooling, async, and mocks/fakes for testing.
• New — version coupling is now a cost line item (v4.0.0): The v4.0.0 release notes call out PHP 8.1's ftp_connect change — it returns an FTP\Connection instance instead of a resource. Any consumer, ours included, now has to reason about runtime PHP version when handling connection objects: resource on ≤8.0, FTP\Connection on 8.1+. That is a breaking type change inherited from the platform, not an improvement to the API, and it is exactly the kind of thing a wrapper is supposed to insulate callers from. Budget for it in any plan that touches ftp_* directly.
• Reference architecture for a first-party adapter: Still valid. The "wrap a procedural extension in a class, register in the container" pattern is worth borrowing; the code is not. v4.0.0 reinforces the point — a wrapper that leaks the underlying return type is a wrapper with a hole in it.
• Roadmap filtering (negative signal, slightly softened): A v4.0.0 after the April 2023 gap shows the maintainer is still reachable — a maintenance pulse, not a revival. With ~22 stars, zero dependents, and a major-version bump driven by a PHP internal change rather than a feature or security fix, this still must not anchor any roadmap commitment. Treat it as a market signal that FTP integration in PHP is underserved, not as a dependency.
• Technology-fit decision (unchanged): This is a Symfony2-era bundle — Bundle suffix, service container config, no service provider, no facade, no config publishing. For a Laravel codebase, adopting it means importing a foreign framework's composition conventions into an app that doesn't use them. Open diligence item: v4.0.0 may have revised framework or PHP requirements; the notes don't say. Confirm before repeating the "legacy Symfony2" characterization to anyone who has read the release. Either way, the Laravel fit answer does not change.

When to Consider This Package

Consider it only under narrow conditions:

• The project is a legacy Symfony 2.x application already using bundles as its unit of composition — the original and only intended context. (Verify v4.0.0 hasn't dropped this support; if it has, this row disappears entirely.)
• You need plain FTP (not SFTP/FTPS) against a partner or appliance that offers nothing better, transfer volume is low, and your runtime is pinned to a single PHP minor so the FTP\Connection vs. resource split is a non-issue.
• You are reading the source for reference while writing your own wrapper — free, non-committal, and still the best use of the repo.
• The work is internal tooling or a one-off migration script, not a customer-facing path where dependency health matters.

Look elsewhere — or build — when any of the following is true:

• You are on Laravel. Use Storage::disk() with the ftp or sftp driver from league/flysystem. It ships natively, is tested, already in the dependency graph, and already absorbs the PHP 8.1 connection-type change for you. There is no reason to add a Symfony bundle to a Laravel app.
• You span multiple PHP versions. With v4.0.0's FTP\Connection handling, the wrapper's behavior is now tied to your runtime. If you run 8.0 and 8.1+ fleets, or are mid-upgrade, you inherit a compatibility matrix you didn't ask for.
• You need SFTP or FTPS. The ftp_* extension does not do SFTP at all and needs explicit ftp_ssl_connect for FTPS. Most partners require SFTP; this is the wrong primitive.
• You need reliability semantics: retries with backoff, resumable/atomic uploads, checksum verification, idempotency, structured error types, observability hooks. None promised, none added in v4.0.0.
• You need to test your integration. The wrapper binds to global ftp_* functions with no injectable transport. Unit-testing callers means a live server or namespace-shadowing tricks — a real CI cost, and v4.0.0 did nothing to make the transport fakeable.
• Dependency governance applies. Zero dependents still means no one has stress-tested this against real workloads. One maintainer plus a long release gap is a bus-factor and patching risk for code you could write in a day.
• You need more than a version-compatibility bump. v4.0.0 is not a feature release, not a security release, and not a reliability release. If you were waiting for those, keep waiting.

How to Pitch It (Stakeholders)

For executives — one line: A new major version of the FTP library was published, but it only adjusts the library to a change in the underlying PHP language; it adds no capability, no reliability features, and no security fixes. Our recommendation is unchanged: do not adopt — the capability is already standard in our stack and we can meet the requirement without a new dependency.

For engineering — the substance:

• What actually shipped in v4.0.0: The notes describe PHP 8.1's behavior change — ftp_connect now returns an FTP\Connection instance where it used to return a resource. That is a platform change the package is reacting to, not a package feature. Read the notes carefully: they explain PHP, not the library, which is itself a documentation-quality tell.
• What it means for us: Any direct ftp_* work we do now has a type-handling fork (resource on ≤8.0, FTP\Connection on 8.1+). Our in-house adapter should normalise that behind our own interface so callers never see it. This is a half-day of care, not a reason to take on the dependency.
• Health check, updated: A v4.0.0 after the April 2023 gap is a positive blip on maintenance — the maintainer is alive. It is not a revival: ~22 stars, 0 dependents, one maintainer, no new features, no security work. Zero dependents still means nobody has validated this in production at scale.
• Capability gaps unchanged by this release: no SFTP (which most partners now require), no retries or resumable transfers, no injectable transport so callers can't be unit-tested without a live server, no structured exceptions, no observability hooks.
• Diligence item before next review: the release notes don't say whether v4.0.0 changed framework or minimum PHP requirements. If it dropped Symfony 2.x support or added typed signatures, parts of our prior framing are stale — but the Laravel fit conclusion is unaffected, because Laravel's own FTP/SFTP support was never the weak link.
• Recommendation (unchanged): implement transfers behind a small internal FileTransfer port, backed by Flysystem's FTP/SFTP adapters, or a direct ftp_ssl_connect wrapper if we truly need raw FTP. Keep the port narrow enough to hide connection-type differences across PHP versions so the transport stays swappable. If a partner forces plain FTP, it ships in the same sprint and we own the retry and error semantics.
• What we take from the package: its method list as our feature checklist, and the reminder — sharpened by this release — that this space is underserved in PHP and that "wrapper" and "abstraction" are not the same thing.

Ask: no budget, no dependency — sign-off on one engineer-day for the first-party adapter (plus a small allowance for PHP 8.1 connection-type handling), and a note that plain FTP is a compatibility fallback, not a default, in any partner-integration standards we publish.