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

Aetherupload Webman Laravel Package

erikwang2013/aetherupload-webman

Brings AetherUpload's large-file upload capabilities to Webman applications. Supports chunked and resumable uploads, configurable storage, and efficient handling of big files, making it a practical integration for Webman projects that need robust upload workflows.

View on GitHub
Deep Wiki
Context7

Getting Started

This release (v1.1.14) is a maintenance cut — "clean up PHP 8.5 deprecations and sync the test baseline." No new API surface, no config keys, no breaking changes. That means the fastest way to start is the same as any Laravel package: install, publish, and wire it into one existing code path rather than building a demo.

  1. Confirm your runtime matrix first. The whole point of this release is PHP 8.5 cleanliness, so check where you actually stand before touching application code:
php -v
composer show --direct | grep -i <vendor>/<package>
composer why-not <vendor>/<package> ^1.1

If you are on 8.4 or 8.5, upgrade to ^1.1.14 and re-run your suite with error_reporting=E_ALL before adopting anything else. The value of this release is silent logs, and silent logs are only observable if deprecations are actually surfaced in CI.

  1. Read the service provider, not the README. For a package that is iterating on deprecations, the provider is the source of truth for what is registered, what is deferred, and whether config is merged or published. Look for mergeConfigFrom, publishes, and any singleton/scoped bindings — those tell you the extension points faster than the docs.

  2. Publish config only if you need to change defaults.

php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider" --tag=config

Copy-then-edit is a trap for packages in active patch releases: a published config file masks newly added keys. Prefer env vars and leave the shipped config untouched until you have a concrete override.

  1. First use case: pick the lowest-risk integration point in your app — a single artisan command, a form request, or one queued job — exercise it end to end, and confirm zero deprecation output in storage/logs/laravel.log. That validates the release's actual claim in your environment.

Implementation Patterns

Pin to a caret constraint and let patch releases flow. ^1.1.14 is the correct constraint here. This is a deprecation-cleanup patch; holding an exact pin means you keep emitting notices on 8.5 for no benefit.

Treat PHP-version compatibility as a CI matrix concern, not a local concern. The release's real assertion is "works cleanly on 8.5." Encode that:

# .github/workflows/test.yml
strategy:
  matrix:
    php: ['8.3', '8.4', '8.5']
    laravel: ['11.*', '12.*']

Run your application suite on 8.5, not just the package's. Deprecations from the package surface in your tests, in your queue workers, and in your HTTP layer — three different boot paths.

Use it behind a container binding rather than static calls. Even when a facade is offered, resolving through the container makes the integration swappable in tests and insulates you from internal refactors in a package that is still being tidied up:

public function __construct(private PackageContract $package) {}

Bind it in your own provider so tests can substitute a fake without touching the package's config.

Wire long-running paths deliberately. If the package participates in queues, Octane, or scheduled tasks, the deprecation cleanup matters most there — a worker that boots once will log a notice once, which is easy to miss and easy to forget. Add one queued job and one php artisan schedule:run invocation to your smoke test.

Adopt in a branch with composer update --with-dependencies. Because the release also "syncs the test baseline," its internal dev dependencies moved. Your production dependency graph is unaffected, but a --with-dependencies run will reveal any transitive constraint you were accidentally relying on.

Version-pin in composer.lock and review the diff. Treat the lock file change as the audit artifact for this upgrade: it shows precisely what moved.

Gotchas and Tips

No changelog entry means no migration guide — so diff the tag. With a one-line release note, git diff v1.1.13..v1.1.14 -- src/ is the only reliable record of what changed. Read it before assuming "optimization" means "no behavioural change"; deprecation cleanup occasionally alters default parameter values or tightens type declarations that were previously loose.

PHP 8.5 deprecations are quiet by default in production. display_errors off plus error_reporting narrowed in php.ini means you may believe you are clean when you are not:

php -d error_reporting=E_ALL -d display_errors=1 artisan about

Run your suite with E_ALL locally at least once per PHP minor.

Implicit nullable parameter types are the usual culprit. Any function f(Foo $x = null) will be flagged on modern PHP. If the package fixed these internally, your own subclasses, decorators, or fake implementations of its interfaces may still carry them. Grep your overrides of any contract the package exposes.

Test baseline sync is a signal, not a guarantee. "Synced baseline" often means updated expectation files and CI images. It does not mean the package's dev dependencies match yours. If your suite suddenly reports failures in assertions that touch the package, check whether you were depending on formatting or ordering that was incidental.

Published config files go stale silently. If you published config in an earlier minor, diff it against the package's current config/*.php after this upgrade. New keys added in patches take effect only when absent from your copy.

Facade caching surprises. If the package offers a facade, remember Facade::clearResolvedInstances() between tests; a stale resolved instance will hide whether the updated code is actually loaded.

Extension point to prefer: bind against the package's interfaces/contracts in your own service provider rather than extending concrete classes. On a package doing internal cleanup across patch releases, interface bindings survive refactors that would break subclass overrides.

Debugging order when something looks wrong after upgrade: (1) composer why the package to confirm the resolved version, (2) clear bootstrap/cache/*.php, (3) run one command with -vvv and E_ALL, (4) only then read the diff from step one. In a maintenance release, the cause is almost always a stale cache or a transitive dependency, not the package itself.

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.
coleus/frame
thtg88/journalism
filagora/filagora-ai-forums
rlacerda83/query-parser
socialdept/atp-orm
cboxdk/laravel-assistant-client
socialdept/atp-resolver
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings