I ran the `bin/console spdx --fix` with different strategies for
different files. For most of the core classes, since they've been
drastically rebuilt, I've run it with the `git-blame` strategy, for for
the `src/Validators`, in which the API changed completely but the logic
remains the same, I use the `git-log` strategy.
This commit introduces REUSE compliance by annotating all files
with SPDX information and placing the reused licences in the
LICENSES folder.
We additionally removed the docheader tool which is made obsolete
by this change.
The main LICENSE and copyright text of the project is now not under
my personal name anymore, and it belongs to "The Respect Project
Contributors" instead.
This change restores author names to several files, giving the
appropriate attribution for contributions.
Mutable objects can be challenging to work with in larger codebases
because different parts of a system may modify the same instance, making
it difficult to trace where and when changes occurred. This becomes
especially problematic when debugging unexpected behaviour.
By making `Validator` immutable, we ensure that adding rules via
`with()` returns a new instance rather than mutating the original, and
we use the `with()` method inside `__call()`, making every call to a
rule into a clone of the current `Validator`.
This provides several benefits:
1. Predictability: A `Validator` instance will always behave the same
way throughout its lifetime, regardless of what other parts of the
codebase do.
2. Safe dependency injection: Users can now confidently inject a base
`Validator` from a DI container, knowing that any modifications made
elsewhere will not affect their instance.
3. Easier debugging: Since validators cannot be mutated after creation,
there's no need to track down where an unexpected rule was added.
4. Reusability: Users can create an initial `Validator` with some base
rules and reuse it by just adding new rules to the chain without
affecting the base `Validator`.
Since we have the ability to use `not` as a prefix, having rules that
validate negative behaviour makes them a bit inflexible, verbose, and
harder to understand.
This commit will refactor the `NotEmpty`, and rename it to `Falsy`. It
will no longer trim strings, because Blank does a much better job at it;
it only simulates the behaviour of PHP’s native `empty()` function.
Because `Falsy`, `Blank`, and `Undef` have similar behaviour, I created
a page to demonstrate the difference and show when the user should use
one or the other.
Assisted-by: Cursor (claude-4.5-opus-high)
Currently, the templates that a user provides when running `assert()`
can significantly impact how the message is displayed. Because of this,
the formatters become complex as they all need to handle similar
conditions to format results.
This commit changes this behaviour, letting only the
`InterpolationRenderer` handle the templates. This makes the code
simpler and allows people to use the `InterpolationRenderer` directly,
without needing to figure out how to handle templates. Thinking about it
further, I believe handling templates is a concern for the `Renderer`
anyway, and this will open the way to other improvements using the
renderer.
I also removed the exception that is thrown when the template is not a
string, because I think that after validation has failed, we should not
throw any other exceptions, as that could cause unexpected errors for
users.
Currently, we’re using scalar values to trace paths. The problem with
that approach is that we can’t create a reliable hierarchy with them, as
we can’t know for sure when a path is the same for different rules. By
using an object, we can easily compare and create a parent-child
relationship with it.
While making these changes, I deemed it necessary to also create objects
to handle Name and Id, which makes the code simpler and more robust. By
having Name and Path, we can create specific stringifiers that allow us
to customise how we render those values.
I didn’t manage to make those changes atomically, which is why this
commit makes so many changes. I found myself moving back and forth, and
making all those changes at once was the best solution I found.
The problem with the current approach is that the "expect()" calls
happen inside "tests/Pest.php". That means that when something fails, we
can't easily know which exact expectation has failed.
This commit will change the helper functions, and will make the tests
more verbose, but event with that, the developer experience is better.
When nested-structural validation fails, it's challenging to identify
which rule failed from the main exception message. A great example is
the `Issue796Test.php` file. The exception message says:
host must be a string
But you're left unsure whether it's the `host` key from the `mysql` key
or the `postgresql` key.
This commit changes that behaviour by introducing the concept of "Path."
The `path` represents the path that a rule has taken, and we can use it
in structural rules to identify the path of an array or object.
Here's what it looks like before and after:
```diff
-host must be a string
+`.mysql.host` must be a string
```
Because paths are a specific concept, I added a dot (`.`) at the
beginning of all paths when displaying them. I was inspired by the `jq`
syntax. I also added backticks around paths to distinguish them from any
other value.
I didn't manage to fix a test, and I skipped it instead of fixing it
because I want to make changes in how we display error messages as
arrays, and it will be easier to fix it then.
Although I love PHPT files, and I've done my fair share of making it
easier to write them in this library, they're very slow, and running
them has become a hindrance.
I've been fidgeting with the idea of using Pest for a while, and I think
it's the right tool for the job. I had to create a couple of functions
to make it easier to run those tests, and now they're working really
alright.
I migrated all the PHPT files into Pest files -- I automated most of the
work with a little script using "nikic/php-parser"; this commit should
contain all the previous PHPT tests as Pest tests.
The previous integration tests would take sixteen seconds, and the Pest
tests take less than a second.
