Pull request: shetabit/visitor — PHP 8.4 explicit nullable visit() parameter

Use this body when opening a PR against shetabit/visitor (master).

Description

Update Shetabit\Visitor\Visitor::visit() so the $model parameter uses an explicit nullable type: ?Model $model = null instead of Model $model = null.

Optionally align the docblock with the signature, e.g. change @param Model $model to @param Model|null $model (behavior is unchanged; only the declared type matches PHP 8.4).

Motivation and context

PHP 8.4 deprecates implicitly nullable parameters: a non-nullable type with a default of null must be written as nullable (?Type or Type|null). Without this, loading the class triggers:

Implicitly marking parameter $model as nullable is deprecated, the explicit nullable type must be used instead

This change removes that deprecation and matches the same nullable style already used elsewhere in the class (e.g. setVisitor(?Model $user)). It is not a behavior change: callers could already pass null via the default; the runtime contract is the same.

If it fixes an open issue, link it here (e.g. Fixes #num or closes #num).

How has this been tested?

• Environment: PHP 8.4.x (or the version where the deprecation appears), Laravel/app context where shetabit/visitor is loaded.
• Static check: php -l src/Visitor.php passes after the edit.
• Package scripts (from the visitor repo root): composer check-style and composer test (or vendor/bin/phpunit) after composer install.
• Manual / app check: Boot the application (or run a request that resolves app('shetabit-visitor')) and confirm the deprecation notice for Visitor::visit() no longer appears in logs.

No other code paths were changed; call sites that pass a Model, omit the argument, or rely on the default remain valid.

Screenshots (if appropriate)

N/A (no UI changes).

Types of changes

What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

Go over all the following points, and put an x in all the boxes that apply.

• I have read the CONTRIBUTING document.
• My pull request addresses exactly one patch/feature.
• I have created a branch for this patch/feature.
• Each individual commit in the pull request is meaningful.
• I have added tests to cover my changes.
• If my change requires a change to the documentation, I have updated it accordingly.

Notes:

• CONTRIBUTING.md asks for tests; if the repo has little coverage, add a minimal smoke test (e.g. visit(null) or resolving shetabit-visitor) so the tests checkbox is accurate.
• Tick the documentation box if you updated the PHPDoc on visit(); the README likely stays unchanged.

Code change (reference)

--- a/src/Visitor.php
+++ b/src/Visitor.php
@@ -270,7 +270,7 @@
      *
      * @param Model $model
      */
-    public function visit(Model $model = null)
+    public function visit(?Model $model = null)
     {

Optional docblock tweak: @param Model|null $model.