Pest Architecture Plugin

 With the release of PestPHP v2, we can now test the architecture of our applications. In this tutorial, we will walk through how to use this plugin.

It starts with creating an ArchTest.php file under tests/Feature in our application. From here, we can begin documenting our architectural requirements and rules - allowing us to test these with a great API and fantastic developer experience.

One test I recommend adding to your tests will ensure no stray debugging calls are left in our application.

test('Not debugging statements are left in our code.')
 ->expect(['dd', 'dump', 'ray'])
 ->not->toBeUsed();

Before we go too deeply into the available rules we could use, let's analyze the structure of these tests. It starts with a test call, where we define the name of the test - make sure this is something understandable that describes what you are testing for. We then use Pest higher-order expectations API to declare what we are testing. We start by expecting something. In the above case, we expect none of the following to be used, or we could expect something to appear.

Next, let's look at more specific tests we can create to ensure our architectural rules are followed. Obviously, the first thing we need to do is ensure we understand what our architectural practices are. You can't simply implement rules you don't intend to follow. During this tutorial, I will document some rules I like to apply to my projects. Being an un-opinionated developer as I am.

test('Our API controllers return responses that we expect')
    ->expect('Illuminate\Contracts\Support\Http\Responsable')
    ->toBeUsedIn('App\Http\Controllers\Api');

In this test, we want to ensure that we use Response classes in our API. Our Controllers should return Responsable classes so that we minimize code duplication and always return in a standard way.

test('We do not directly use Eloquent Models in our APIs.')
    ->expect('App\Models')
    ->not->toBeUsedIn('App\Http\Controllers\Api');

In this test, we want to ensure that we do not directly use Eloquent models in our API. We should use Action, Command, Query, or Service/Repository classes when working with the database. This is a rule I like to follow as much as possible as, again, it reduces code duplication.

test('We always use Resouce classes when responding')
    ->expect('App\Http\Resources')
    ->toBeUsedIn('App\Http\Controllers\Api');

In this test, we want to ensure we always use Resource classes in our controllers. This allows us to ensure that we have a standardized way to return data from the API.

The following rules will be more specific to how I code, so it may not be relevant to you - but it shows particular ways you can test the modular aspects of your code.

I lean heavily on my modular approach to Laravel, using separate namespaces where I need them. I also lean heavily on Commands for write actions and Queries for read actions. I can ensure that these are used where it makes sense to me.

test('We use Query classes where we need them in the Catalog domain')
    ->expect('Domains\Catalog\Queries')
    ->toBeUsedIn('App\Http\Controllers\Api\V1\Products\Read');

This is currently something that I would use as a temporary measure until the architecture plugin supports wildcards. We want to make sure that We are using queries in the right place. As soon as we allow wildcards in the architecture plugin, we can do something like this:

test('Query classes are used for read operations')
    ->expect('Domains\*\Queries')
    ->toBeUsedIn('App\Http\Controllers\Api\*\*\IndexController')
    ->toBeUsedIn('App\Http\Controllers\Api\*\*\ShowController')
    ->not->toBeUsedIn('App\Http\Controllers\Api\*\*\StoreController')
    ->not->toBeUsedIn('App\Http\Controllers\Api\*\*\UpdateController')
    ->not->toBeUsedIn('App\Http\Controllers\Api\*\*\DeleteController');

With this test, we can ensure that we are using queries in all of our read endpoints but not the write endpoints, allowing us to keep a tighter grip on our code architecture and approach.

Of course, this is not available right now, but perhaps it will allow us to have fewer architectural rules and the same amount of coverage in the future.

Read More

http://dlvr.it/SlgtJl

Read More

Laravel Ciphersweet is a package by Spatie

Laravel Ciphersweet is a package by Spatie to integrate searchable field-level encryption in Laravel applications. The package's readme explains the problem Ciphersweet can help solve as follows:In your project, you might store sensitive personal data in your database. Should an unauthorised person get access to your DB, all sensitive can be read which is obviously not good.To solve this problem, you can encrypt the personal dat
http://dlvr.it/SlgMrb

Read More

Laravel 10.4 Released

 The Laravel team released 10.4 with a File::json() method, converting existing HasMany relationships to a HasOne relationship, a new test response assertion, and more.

File::json() method

Austin White contributed a File::json() method as a convenience for getting JSON encoded data from a file:

// Before
$contents = File::get('sample.json');
$data = json_decode($contents, true);
 
// After
$data = File::json('sample.json');

Assert unsupported media type

Shamimul Alam contributed an assertion helper for the 415 Unsupported Media Type response status code:

$response->assertUnsupportedMediaType();

Convert an existing HasMany to HasOne relationship

Luke Kuzmish contributed converting a HasMany to a HasOne and a MorphMany to MorphOne

Take this example of having to define two relationships:

class User extends Model
{
    public function logins(): HasMany {
        return $this->hasMany(Login::class, 'some_id', 'the_other_id');
    }
    public function latestLogin(): HasOne {
        return $this->hasOne(Login::class, 'some_id', 'the_other_id')->latestOfMany();
    }
}

With this PR now, you can do the following instead with the ->one() method:

class User extends Model
{
    public function logins(): HasMany {
        return $this->hasMany(Login::class, 'some_id', 'the_other_id');
    }
    public function latestLogin(): HasOne {
        return $this->logins()->one()->latestOfMany();
    }
}

The one() method is available on the HasMany, HasManyThrough, and MorphMany.

Create macroable method for paginationInformation

Frans Slabbekoorn contributed the ability to define a macro for paginationInformation that allows customizing pagination information without having to extend all resources as a base resource:

/** @mixin \Illuminate\Http\Resources\Json\ResourceCollection */
class ResourceCollectionMixin
{
    public function paginationInformation(): Closure
    {
        return fn ($request, $paginated, $default) => collect($default)->mapWithKeysRecursively(fn ($item, $key) => [Str::camel($key) => $item])->toArray();
    }
}

Release Notes

You can see the complete list of new features and updates below and the diff between 10.3.0 and 10.4.0 on GitHub. The following release notes are directly from the changelog:

v10.4.0

Added

• Added Illuminate/Testing/Concerns/AssertsStatusCodes::assertUnsupportedMediaType() (#46426)
• Added curl_error_code: 77 to DetectsLostConnections (#46429)
• Allow for converting a HasMany to HasOne && MorphMany to MorphOne (#46443)
• Add option to create macroable method for paginationInformation (#46461)
• Added Illuminate/Filesystem/Filesystem::json() (#46481)

Fixed

• Fix parsed input arguments for command events using dispatcher rerouting (#46442)
• Fix enums uses with optional implicit parameters (#46483)
• Fix deprecations for embedded images in symfony mailer (#46488)

Changed

• Added alternative database port in Postgres DSN (#46403)
• Allow calling getControllerClass on closure-based routes (#46411)
• Remove obsolete method_exists(ReflectionClass::class, 'isEnum') call (#46445)
• Convert eloquent builder to base builder in whereExists (#46460)
• Refactor shared static methodExcludedByOptions method to trait (#46498)

Read More