DEV Community: Davey Shafik

Laravel Pipelines & Composable Job Middleware

Davey Shafik — Wed, 02 Oct 2024 09:54:57 +0000

A feature you are probably familiar with in Laravel — even if you don't know it — is the Pipeline.

Laravel features a Pipeline implementation that allows you to easily create a series of pipes through which a value should pass:

use \Illuminate\Pipeline\Pipeline;

$pipeline = new Pipeline(null);

$greeting = $pipeline->send(new Stringable(''))
     ->through(
         fn (Stringable $greeting, Closure $next) => 
             $next($greeting->append('Hello World!')
     )
     ->then(fn (Stringable $greeting) => $greeting->toString()); 

// Hello World!

What the heck is a Pipe?

A pipe is a callable, or any class with a specific public method (by default: handle()) — it should take two arguments, a "passable", and a Closure. The passable is the value you are sending through the pipeline, and the Closure is a wrapper that will call the next pipe in the pipeline, passing through the argument passed to it (which should be the passable) and handle the return value.

In the example above, the pipe is a short closure that accepts our Stringable passable, and then calls the $next closure passing in a modified string.

A more complex set of pipes might look like this:

use Illuminate\Support\Arr;
class Greeting {
    public function __invoke(Stringable $str, Closure $next)
    {
        $greetings = ['Hey', 'Hello', 'Hi', 'Hola', 'Howdy'];

        $str = $str->append(Arr::random($greetings));

        $str = $next($str);

        return $str->finish('!');
    }
}

use Illuminate\Support\Facades\Auth;
class AddName {
    public function handle(Stringable $str, Closure $next)
    {
        if (Auth::hasUser()) {
            $str = $str->append(' ')->append(Auth::user()->name);
        }

        return $next($str);
    }
}

$pipeline = new Pipeline(null);
$greeting = $pipeline
    ->send(new Stringable(''))
    ->through([
        Greeting::class,
        AddName::class,
    ])
    ->then(fn (Stringable $greeting) => $greeting->toString());

These two pipes work together to construct a greeting:

The first pipe (Greeting) will add a random friendly greeting word
Then it will call the second pipe (AddName) that will conditionally add the users name
Finally the updated string will be returned back to the first pipe to make sure it ends in an exclamation point.

It looks something like this:

Using a different handler method

If you look closely at the example above, I use __invoke() with the first pipe, but handle() on the second. The Pipeline class will accept any valid callable, or, if it's a string, it will resolve the class using the service container and if invokable (has __invoke()) it will execute that, otherwise it will use the handler method, which defaults to handle().

You can change the named handler method by calling Pipeline->via():

$result = $pipeline
    ->send($passable)
    ->through(…)
    ->via('METHOD NAME HERE')
    ->then(…);

Why Does This Look So Familiar?

If this is starting to look familiar, it's because it looks a heck of a lot like HTTP middleware… right? Well, that's because it is HTTP middleware… or rather, internally, Laravel uses Pipelines for multiple different things, including the HTTP request lifecycle:

// Illuminate\Foundation\Http\Kernel->sendRequestThroughRouter()

return (new Pipeline($this->app))
    ->send($request)
    ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware)
    ->then($this->dispatchToRouter());

Job Middleware

What you might be surprised to find out is that Laravel Jobs also go through a pipeline when executed, and can also have middleware.

Job middleware is extremely powerful, it can be used to track metrics about your jobs, to handle errors, to verify that a job hasn't expired for some reason, or whatever else you can imagine.

Example: Authenticated Users in Jobs

A common problem that is encountered when reusing (particularly older code) within jobs is that they are tightly coupled to authentication using the Auth facade to retrieve the user, and this fails because a job running in the background is no longer executing within the users authenticated web session.

We can use middleware to ensure that jobs that require an authenticated user are logged in during job execution:

use Illuminate\Queue\Jobs\Job;

class Auth {
    public function __invoke(Job $job, Closure $next)
    {
        if (method_exists($job, 'getUser')) {
            Auth::login($job->getUser());
        }

        return $next($job);
    }
}

Composable Job Middleware

A common pattern in Laravel is to use traits to add features to classes, for example HasTimestamps, SerializesModels, etc.

This would be a great way to add middleware to our jobs. Laravel will automatically call a jobs middleware() method which should return an array of middleware to add to the pipeline. We can use this feature to create composable middleware.

The `HasMiddleware` Trait

The goal of the HasMiddleware trait is to add a middleware() method that will dynamically create an array of middleware based on the traits it uses. To do this, for each middleware we create a trait that has a middleware<TraitName>() method — e.g. for the HasDeadline middleware trait, it would have a middlewareHasDeadline() method — which is called by the middleware() function and it's result is added to the list of middleware.

namespace App\Jobs\Traits;

use function class_basename;
use function class_uses_recursive;
use function method_exists;

trait HasMiddleware
{
    public function middleware(): array
    {
        $middleware = [];
        if (method_exists(parent::class, 'middleware')) {
            $middleware = parent::middleware();
        }

        foreach (class_uses_recursive($this) as $trait) {
            $method = 'middleware' . class_basename($trait);
            if (method_exists($trait, $method)) {
                $middleware = array_merge($middleware, $this->{$method}());
            }
        }

        return $middleware;
    }
}

You can then add middleware by creating a trait:

namespace App\Jobs\Traits;

use App\Jobs\Middleware\Auth;

trait HasAuth {
     use HasMiddleware;

     protected function middlewareHasAuth(): array
     {
         return [Auth::class];
     }
}

You Job class can then use the HasAuth trait:

use App\Jobs\Traits\HasAuth;

class MyJob extends Job {
    use HasAuth;

    public function __invoke()
    {
        // Auth::user()
    }
}

This trait uses the HasMiddleware trait itself so that the job doesn't need to use it explicitly in addition to the HasAuth trait.

Creating Job Middleware

Starting in Laravel 11.26, you can now use the artisan make:job-middleware command to generate Job middleware.

In Summary…

The Laravel Pipeline is very versatile — although for Bag I went with League\Pipeline as it was faster and functionally, it's almost identical — and can be used for any composable series of operation that act on a value — be that HTTP request middleware, Job middleware, or anything else you want.

Finding Terminal Utopia

Davey Shafik — Wed, 22 May 2024 09:57:11 +0000

For the last few weeks I’ve been setting up a new laptop from scratch for the first time in a… very long time, taking the time especially to re-evaluate my terminal setup and integrating some new tools, and re-integrating some old tools in a new way.

Note: Almost all of the tools and scripts mentioned below can be easily installed using homebrew. If you want to use my .zshrc config as-is, you’ll want to use homebrew.

If you want to skip ahead and see the final outcome, checkout the screencast at the end of this post.

Building a Better Prompt

Everything in the terminal starts with your prompt. Before I moved to zsh, I used bash-it with bash to create a fancy prompt that gave me things like current directory, git status and branch, and tool versions. Moving to zsh, I installed oh-my-zsh and my prompt took a giant leap forward with display of command exit status, command timing, icons, and more tool versions. Unfortunately, my prompt got so bloated that I started to dread opening a new terminal.

Thankfully, I found Starship, a super fast, super configurable prompt written in Rust. It works with most shells, on most operating systems.

Even with additional prompt information like Kubernetes context and namespace, Google Cloud CLI version, and a prettier (to me!) more usable prompt, it’s blazing fast.

Here you can see that I’m in the bag directory, which is on the main branch with some untracked files, using NodeJS v22.2.0, and PHP 8.3.7. You can also see that the previous command took five seconds to run, and the current (24 hours) time, and you can see how quickly it renders using starship explain:

As you can see, the total rendering time is less than 150ms. And my configuration (which is minimally updated from the default) includes support for dozens of other languages and useful information.

After the Prompt

Before we add any other applications, let’s add some zsh scripts to make using the parts after the prompt nicer.

First, we’re going to configure how zsh stores your history. The history is a log of every command you’ve entered into the shell. We are going to set the following options:

# Save the history in your home directory as .zsh_history
export HISTFILE=$HOME/.zsh_history 

# Set the history size to 2000 commands
export HISTSIZE=2000               

# Store the same number to disk
export SAVEHIST=$HISTSIZE          

# Share history between sessions
setopt share_history               

# Remove duplicates first when HISTSIZE is met
setopt hist_expire_dups_first      

# If a command is issued multiple times in a row, ignore dupes
setopt hist_ignore_dups  

# Allow editing the command before executing again
setopt hist_verify                 

# Do not add commands prefixed with a space to the history
setopt hist_ignore_space

Next, let’s change how we interact with the history. By default, you use Ctrl+r or Ctrl+Shift+R which will bring up the bck-i-search UI, that will match history commands as you type, to navigate forward or backwards from the current match you need to then press Ctrl+r or Ctrl+Shift+R again multiple times until you find the item you want.

This is not intuitive, or efficient, so our first task is fix that using zsh-autosuggestions. zsh-autosuggestions will provide autocomplete suggestions from your history (and other locations) as you type, simply press the right arrow key, or use the end-of-line keyboard shortcut (e.g. ctrl+e) to accept the suggestion. If you only want part of a suggestion, you can use the forward-word keyboard shortcut, which is option+right arrow or alt+right arrow which will complete only up to the end of the next word and continue providing suggestions from there.

This works great if you can remember the exact start of the previous command you want to use, but what if you only remember part of it? Enter zsh-history-substring-search. This script allows you to navigate your history using substring matches, and you can bind it to your up and down arrow keys so that you can simply type the substring and then hit the up key to start finding matches.

Lastly, let’s make what commands we’re running easier to read, using zsh-syntax-highlighting. This script (which must be loaded before the zsh-history-substring-search above) will provide syntax highlighting of commands as you write them. This will help you avoid typos for incorrect commands, and make complex commands easier to read.

Changing Directories For The Better

One of the most — if not the most — common commands that I use is cd. A very simple commands, it changes your current working directory to the one specified.

One simple trick to improve your use of cd is knowing that cd - will take you back to whatever directory you were previously in. This alone had a massive impact on my ability to navigate around my directory structure.

There is, however, an even better solution: zoxide, a cd alternate, and can be used as a drop-in replacement.

zoxide uses fuzzy matching and a frequency of usage ranking to intelligently let you change directories based on substrings. For example, to reach the bag repo that lives at ~/src/bag, I can use cd bag from anywhere, if however I want to enter the bag-benchmarks repo, I can use cd bag- and it will take me there instead.

Under the hood, zoxide uses fzf for completions and interactive selection, but fzf‘s utility doesn’t end there.

Finding Clarity Through Fuzziness

fzf is really the hero of this story, as it can integrate into many different aspects of your terminal to bring improvements.

For example, it can be used as part of tab suggestions. When you hit <tab> to get suggestions, it will display a UI with a keyboard navigable, searchable, list of possibilities:

This also works for arguments:

But fzf can do so much more. To expand on it’s capabilities, let’s add two helpers: fd and eza.

Find Everything

fd is a simpler, faster alternative to find, which is valuable in and of itself, but paired with fzf, it can enable faster/better suggestions. Adding the following will use fd for both file and folder completion:

_fzf_compgen_path() {
    fd --hidden --exclude .git . "$1"
}

_fzf_compgen_dir() {
    fd --type=d --hidden --exclude .git . "$1"
}

With this in place, fzf will suggest both directories and files (except .git) when trying to auto-complete paths (see above screenshot with ls), but will only show directories (except .git) when using commands like cd that only accept a directory:

Show Everything

eza is a drop-in replacement for ls, and provides a much richer file list experience, from adding rich colors, to showing icons and git status.

I alias eza to ls with the following options:

alias ls="eza --icons=always --color=always --git"

This allows me to continue to use ls the way I always have (compact format by default, adding -al to show all files in list format) but will add eza colors, icons, and show git information is list view.

For example, calling ls -al will show the following:

Here you can see the standard ls -al style output but with excellent highlighting, as well as the introduction of git status (between the date time and the icon) and the icons.

WARNING: eza expects you to be using a nerdfont, which you will install as part of installing Starship, but if you chose not to do so, you will want to do that separately. I use SauceCodePro.

See Everything

Now that you have eza installed, you can setup fzf previews, which can be context aware, similar to the file and directory lists shown when tab completing those.

For example, with the integration of eza and fzf, that list of directories for cd can include a tree-based preview of the selected directory. To invoke fzf you use the placeholder ** and then hit <tab>, e.g. cd** could show the following:

You can then make your selection using the up/down arrow keys and hit <enter> to replace the ** with the selected directory.

With some additional configuration, and a simple script, we can show either a directory tree preview, or use bat to show a syntax highlighted preview of the file contents.

Add the following to your .zshrc:

 _fzf_comprun() {
   local command=$1
   shift

   case "$command" in
     cd) fzf --preview 'eza --tree --color=always {} | head -200' "$@" ;;
     export|unset) fzf --preview "eval 'echo \$'{}" "$@" ;;
     ssh) fzf --preview 'dig {}' "$@" ;;
     cat|bat) fzf --preview 'bat -n --color=always {}' "$@" ;;
     *) fzf --preview '$HOME/bin/fzf-preview.sh {}' "$@" ;;
   esac
 }

Add the following as an executable script at $HOME/bin/fzf-preview.sh:

#!/bin/bash
if test -d "$@"; then
    eza --tree --color=always --icons=always --git "$@" | head -200
else
    bat -n --color=always "$@"
fi

Lastly, we can override the default <tab> completion behavior to use fzf with preview by adding the following configuration (and using the same fzf-preview.sh script above) by adding the following to your .zshrc:

 # Enable using fzf preview with eza when using tab completion with `cd`
 zstyle ':completion:*' menu no
 zstyle ':fzf-tab:complete:*' fzf-preview '$HOME/bin/fzf-preview.sh $realpath'
 zstyle ':fzf-tab:complete:cd:*' fzf-preview 'eza --tree --color=always --icons=always --git $realpath | head -200'
 zstyle ':fzf-tab:*' switch-group '<' '>'

Reaching Nerdvana

Now that you know all the pieces, you need to put them together, which is why I have made my entire .zshrc available here.

With this .zshrc you will have the following features:

Starship prompt
command syntax highlighting
automatic suggestions for completions as you type
substring search using the up/down keys
zoxide for a better cd experience (aliased)
eza for a better ls experience (aliased)
fd for better file search
fzf for fuzzy finding and previews with <tab> activation for directories and files

You can see a demo of all of these features below:

While you don’t need to adopt all of these tools and features, together they create a powerful terminal experience.

Is there something missing? Let me know in the comments below!

If you want to learn more about bat, used to show syntax highlighted file previews, and other developer-focused tools, check out my earlier post: Five Must-Have Command Line Tools for Developers

Five Must-Have Command Line Tools for Developers

Davey Shafik — Tue, 21 May 2024 00:49:48 +0000

There are many tools that I use to improve my terminal experience, these are the top five that I use every single day to make developing code easier, quicker, and more enjoyable.

ack

Starting with the most well known first, ack is like grep but optimized for programmers, it is both faster and simpler than grep, and has better results.

ack has several quality of life improvements by default: recursive by default (but ignores VCS folders like .git), better output display including highlighting, and it uses PCRE for pattern matching.

Just compare the default output for grep -R and ack (respectively):

Search for “Interface” in the “src” directory using grep: grep -R Interface src

The same search using ack: ack Interface src

Sure, the output for ack takes up far more space, but it groups matches by filename (highlighted), adds line numbers, and highlights the matching text.

Additionally, you can easily include specific file types using the -t or --type= flags, e.g. to only search PHP file types which includes .php .phpt .php3 .php4 .php5 .phtml and files with a PHP shebang (e.g. #!/usr/bin/env php) on the first line you can use -t php or --type=php. You can also use the type name itself as a flag instead e.g. --php.

You can easily expand these types by adding a .ackrc file to your HOME directory and with a few lines either add additional file matches, or add a new file type entirely. For example, you can use --type-add to add composer.json (specifically) as a filename to search when searching through php file:

--type-add=php:is:composer.json

You can create a new file type for .env files called env:

--type-set=env:ext:env
--type-add=env:match:/^.env.*$/

Or to create a new file type for blade templates:

--type-set=blade:match:/.blade.php$/

With these in place a search for ack --php dshafik/bag will return results from composer.json, while a search for ack --blade someVariables will only match results in *.blade.php files, and ack --env APP will match all lines containing APP in your .env* files.

delta

delta describes itself as “a syntax-highlighting pager for git, diff, grep, and blame output”, but I find that to be somewhat ambiguous: it is a syntax-highlighting pager for git diff, git grep, and git blame output. It will actually be used by all git operations that output diffs, not just git diff.

Integration with git is easy, just add the following to the .gitconfig file in your HOME directory:

[core]
pager = delta

[interactive]
diffFilter = delta --color-only

[delta]
navigate = true # use n and N to move between diff sections

# delta detects terminal colors automatically; set one of these to disable auto-detection
# dark = true
# light = true

[merge]
conflictstyle = diff3

[diff]
colorMoved = default

Personally, I also like to add line-numbers = true to the [delta] configuration to enable line numbers.

Once you’ve completed this, gitwill start to output much easier to read diffs:

delta output with git diff

As you can see here, it calls out the filename at the top, and is smart enough to show the relevant code structure that contains the change and the line on which the diff context starts, in this case the namespace, starting from line 7, but it could also be a class or a function or method. It also features per-character diff highlighting, on top of the standard line highlighting — in this case you can see that I added a new value to the Attribute options bit mask.

httpie

The next tool has been in my toolkit for a long time, httpie, a python tool for making HTTP requests. It is usually referred to as “curl for humans”. Once installed, httpie is available as the http command, which then folllows a syntax similar to the HTTP protocol itself:

http <METHOD> <URL> <HEADER>:<HEADER VALUE> <HEADER2>:<HEADER2-VALUE>

for example, this will display the response from bagvalueobjects.com:

http GET https://bagvalueobjects.com

By default, it will show the response headers and the response body, but this is easy to change using the -p flag. The following will show only the request and response headers:

http -pHh GET https://bagvalueobjects.com

The value for -p are H (request headers), h (response headers), B (request body), b (response body).

Request headers and body? Well, yes, you can send POST requests just as easily:

http -pHhBb POST http://httpbin.org/post foo=bar

You can see that we have a new argument at the end foo=bar, this will send a JSON body with the value {"foo":"bar"}. You can add as many properties as you like to the end of the command. You can also pass the -f or --form argument and it will send the key-value pairs as multipart/form-data instead.

If you need to send complex JSON, use := instead, like so:

http -pHhBb POST http://httpbin.org/post foo:='["bar", "baz", "bat"]'

This will send the body {"foo":["bar", "baz", "bat"]}.

There are tons of other options including being able to use files as the post body, send files, support for sessions, authentication and more.

gron

Many folks are familiar with jq, a great command line utility for working with JSON, if you’re not familiar with it, I highly recommend that you check it out.

Sometimes however, jq is just too complicated, or the result isn’t exactly usable. Sometimes, you just want to be able ack (née grep) some JSON for a specific value. gron will break down JSON into valid Javascript assignments, for example, the simple body from our httpie example above might looks like this:

json = {};
json.foo = [];
json.foo[0] = "bar";
json.foo[1] = "baz";
json.foo[2] = "bat";

As you can see, this creates a variable json, and assigns an empty object to it, it them sets the foo key to an empty array, and then sets each of the numeric keys to it’s specific value.

Because it’s broken down to one assignment per line, you can now easily and reliable pipe it through ack or grep and find whatever you need.

A more practical example: list all the require-dev requirements in a composer.json files:

gron composer.json | ack require-dev

This will output the following:

json["require-dev"] = {};
json["require-dev"]["captainhook/captainhook-phar"] = "^5.23";
json["require-dev"]["captainhook/hook-installer"] = "^1.0";
json["require-dev"]["fakerphp/faker"] = "^1.23";
json["require-dev"]["infection/infection"] = "^0.28.1";
json["require-dev"]["larastan/larastan"] = "^2.0";
json["require-dev"]["laravel/pint"] = "^1.15";
json["require-dev"]["orchestra/testbench"] = "^8.0|^9.0";
json["require-dev"]["phpunit/phpunit"] = "^10.5|^11";
json["require-dev"]["ramsey/conventional-commits"] = "dev-allow-sf-7";
json["require-dev"]["roave/security-advisories"] = "dev-latest";
json["require-dev"]["symfony/var-dumper"] = "*";

We can then turn this back into JSON, and feed it into jq to get the values using gron -u or gron --ungron:

gron composer.json | ack require-dev | gron -u | jq '."require-dev" | keys[]'

This will output:

"captainhook/captainhook-phar"
"captainhook/hook-installer"
"fakerphp/faker"
"infection/infection"
"larastan/larastan"
"laravel/pint"
"orchestra/testbench"
"phpunit/phpunit"
"ramsey/conventional-commits"
"roave/security-advisories"
"symfony/var-dumper"

Alternatively, let’s use gron to remove any custom scripts from our composer.json. We can use this by again, piping the output through ack, but this time using the -v argument to exclude matches, and then passing it back to gron -u:

gron composer.json | ack -v json.scripts | gron -u

The resulting JSON will be identical to the original, but with the entire scripts key missing.

bat

The last tool I want to cover is a new addition to my local environment, and that is bat, a replacement for cat with syntax highlighting.

bat has a few advantages over cat besides syntax highlighting by default: the output is paged, includes the file name, and line numbers:

syntax highlighted code using bat

While bat doesn’t provide as much utility as most of the other tools on this list, it’s simplicity makes it perfect as a drop-in replacement for cat, allowing you to just add alias cat=bat to your terminal configuration and forget about it.

Next Steps

If you want to try any of these tools for yourself, they are all available using brew, which is available on all platforms.

This list was aimed specifically at improving your development workflows, however, I have also made many changes to my terminal environment as a whole which also aids me in getting my work done faster, and easier. If you want to hear more, let me know in the comments below!

Introducing Bag 1.0: Immutable Values Objects for PHP

Davey Shafik — Sun, 19 May 2024 02:15:44 +0000

For the last couple of years I’ve been using Value Objects in my projects to bring language-level strict types to what would typically be array data structures in my code. From method inputs to JSON API responses, value objects have almost entirely replaced arrays throughout. The ability to get runtime type checking and IDE auto-complete has eliminated many potential bugs, from key typos, to assigning an incorrectly typed value by accident: what type is an “amount” property in a credit card transaction API response? An integer of cents (or other minor units), a Money object such as brick/money or moneyphp/money? Or worst of all, a float?

About 18 months ago, I started using the excellent spatie/laravel-data v3 package for a new project, but I quickly realized there were a few features missing, most notably, factory support. Additionally, the collection class didn’t extend the Laravel Collection class and is anemic by comparison.

Note: spatie/laravel-data v4 adds support for factories, and has a slightly more capable DataCollection class. See below for details.

So I extended the base Data class and added factory support, following a similar pattern to Eloquent factories, including support for Sequences, and I extended DataCollection to add some missing functionality, and mostly, it was good.

Enter Spatie/Laravel-Data v4

Earlier this year, Spatie released v4 with support for Laravel 11 (and up until last month, no support for Laravel 11 in v3), with significant changes, including support for Factories, and a better DataCollection class. Unfortunately, the Factories built into v4 were incompatible with my own, and didn’t have the same feature set, and while better, the updated DataCollection class was still lackluster.

The upgrade process was difficult, and while ultimately successful, I was unhappy with the outcome. Then I decided that I would much prefer if my value objects were immutable, which was impossible using either v3 or v4, and ultimately, that, along with the difficult upgrade path to v4, led me to create Bag.

What is Bag?

Bag is a new library built from scratch — inspired by spatie/laravel-data — that provides immutable value objects for PHP. Built on top of Laravel’s excellent Validation and Collection classes, as well as Eloquent Factory Sequences, it is the value object library I wanted spatie/laravel-data to be.

Additionally, I leaned harder into the use of Attributes, for identifying Collection classes to be used for each value object class, wrapping, hiding data in both toArray() and toJson()/jsonSerialize(), and for identifying transformers (what Spatie calls “magical data object creation“).

I simplified input/output casting (as opposed to casting being for inputs, and transformers being for output),

I also added support for Variadics, something that the Spatie library does not allow. For a more detailed comparison of the two libraries, see the Bag documentation here.

Performance

Despite having a few more features, simple benchmarks of Bag do show it as being about 40-45% faster than spatie/laravel-data v4, and a whopping 70-78% faster than v3.

Benchmark Methodology

The benchmark script was intentionally very simple, using Laravel’s Benchmark class to get the average of 10 runs of a loop (default: 1000 iterations) that creates instances of a Bag or Spatie value object. I ran it both with 1,000 iterations and 10,000 iterations.

The value objects have the following features:

Class-level Input/Output Name Mapping to/from SnakeCase
A single property input name mapping from CamelCase
A single property input name mapping from an alias
A property with integer and required validations
A property input/output case from/to DateTime/formatted date string

You can see all the code for the benchmarks here.

Current results look like the following:

Iterations	Bag	Spatie v3	Spatie v4	Difference (ms)	Difference (% Faster)
1,000	427.693ms	975.182ms		-547.489	+78.63%
1,000	429.019ms		679.554ms	-250.535	+45.2%
10,000	4,663.161ms	9,906.135ms		-5,242.974	+71.96%
10,000	4,483.669ms		6,914.524ms	-2,430.851	+42.68%

Example Benchmark Data

What’s Next?

If you want to try out Bag, check out the Getting Started documentation.

For Bag, currently I consider it to be feature complete and have released v1.0.0. I am currently working on support for Bag-less value objects: that is, support for using any class as a value object — if you want to contribute to this idea, you can comment on the RFC.

And with that, I’ll leave you with the adorable mascot for Bag for you to enjoy: