Mpdf Wrapper Laravel Package

Getting Started

Start with the config file and the published service provider stub — that is where argument settings are declared and where the package wires its container bindings. In 3.0 the argument-settings surface was expanded, so read the config file shipped in the release rather than copying your old one forward; new keys generally land with sane defaults, but the shape of nested argument definitions is worth eyeballing before you migrate.

Your first use case should be the smallest thing you actually ship: one function definition with two or three typed argument settings, invoked from a controller or a queued job. Get that working end-to-end before touching anything that composes functions or overrides resolution, because the 3.0 changes to functions sit underneath that composition layer and will surface there first.

Practical order of operations:

1. composer require the 3.0 tag on a branch, run the test suite before changing any code — the failure list is your migration plan.
2. Open the upgrade notes and the CHANGELOG side by side with git diff on the previous tag's src/ — with release notes this terse, the diff is the source of truth.
3. Read the argument-settings classes (Arguments, Argument, any Setting/Definition value objects) before the function classes; settings are the new centre of gravity in this release.
4. Wire one function into a feature test, assert the resolved arguments, then expand.

If your app only reads arguments and never defines its own functions, you are on the easy path: most 3.0 breakage concentrates in the definition/registration side, not the consumption side.

Implementation Patterns

Define functions in a dedicated provider. Register function definitions in a single service provider rather than scattering them through controllers. It gives you one file to audit during upgrades and one place to see the full argument-settings vocabulary in use.

Keep argument settings declarative. Favour the config/array form over imperative setters where the package offers both. Declarative settings survive refactors and diff cleanly; chained ->setX() calls are exactly the surface most likely to shift between majors.

Treat argument settings as a schema, not a dumping ground. Validate incoming values at the boundary — a FormRequest or a small dedicated validator — and let the package handle resolution and coercion. Mixing the two produces errors that are hard to attribute.

Bind and resolve through the container. Inject functions rather than instantiating them, so tests can swap implementations. A container binding plus $this->app->instance(...) in a test is usually enough to isolate the function layer.

Compose functions in small steps. Where functions call functions, test each link against explicit argument settings. The 3.0 change to function behaviour means a single wrong assumption at the leaf will look like a composition bug three layers up.

Feature-test the integration, unit-test the settings. Argument-settings objects are cheap to unit test and give precise failure messages. Reserve feature tests for the wiring: provider registration, container resolution, and one happy-path invocation per function.

Use it for the boring parts. The package earns its keep on repetitive argument plumbing — defaults, optional values, coercion, null-vs-missing handling. If you find yourself using it for domain logic, you have probably inverted the dependency.

Gotchas and Tips

"Functions has been changed" is doing a lot of work. That phrasing signals breaking changes to signatures or behaviour, not additive ones. Assume any subclass, interface implementation, decorator, or macro you wrote against the function classes needs re-verification. Grep for extends, implements, and any method you override on those classes.

Argument settings improvements are usually additive but not always compatible. New settings generally arrive with defaults, but renamed or restructured keys will fail silently — a setting that no longer matches its key is simply ignored on many config-driven implementations. Assert the effect of each setting in a test, not merely that resolution succeeds.

Don't copy the old config over the new one. Publish fresh, then port your customisations across deliberately. Blindly merging is the single most common cause of "the upgrade did nothing" reports.

Watch precedence. Argument settings frequently resolve through several layers — inline definition, config default, environment override. When a value is wrong, log the resolved settings object before the function body runs rather than adding dump() calls inside the logic.

Beware stale caches. config:clear, cache:clear, and a fresh composer dump-autoload after upgrading. Cached config and cached container bindings produce failures that look like code bugs and waste an afternoon.

Debug from the outside in. Dump the full resolved argument settings for one invocation before assuming the package is at fault. Nine times out of ten the input shape changed, or a setting you believed was applied never matched its key.

Extension points to check first after a major. Custom resolvers, macros, and anything registered via extend() are the least stable surface across majors. If you have those, they are your highest-risk code and deserve a test each before you merge.

Pin the minor while migrating. Install the exact 3.0.x tag, finish the migration, then loosen to ^3.0. You do not want a patch release landing mid-refactor on code you are already unsure about.

Upgrade checklist. Branch, bump the constraint, run tests, read the src/ diff, re-publish and port config, audit subclasses and macros, add assertions for each argument setting you rely on, clear all caches, then merge.