This guide has been written with the current latest versions of the libraries:

• PEST 2.6.2
• Laravel 10.13.1

InsTALLATION

• Install Laravel using any of their methods detailed in the Official Documentation
• Install PEST using Composer. The flags in this command are very important as it’s likely that you’ll have conflicting dependencies and this will take care of that for you:

composer require pestphp/pest --dev --with-all-dependencies

• Install the Laravel Plugin for PEST

composer require pestphp/pest-plugin-laravel --dev

• At this stage the installation should be complete and running the following you can verify that things are working as they should

./vendor/bin/pest --version

The above should output the installed PEST version, which in my case is 2.6.2

php artisan pest

The output here should be the ‘Available commands for the “pest” namespace

Installation Troubleshooting

Info from https://repo.packagist.org: #StandWithUkraine
./composer.json has been updated
Running composer update pestphp/pest
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - pestphp/pest[v0.1.0, ..., v0.2.4] require php ^7.3 -> your php version (8.1.19) does not satisfy that requirement.
    - pestphp/pest[v0.3.0, ..., v0.3.19, v1.0.0, ..., v1.4.0] require nunomaduro/collision ^5.0 -> found nunomaduro/collision[v5.0.0, ..., v5.11.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.5.0, ..., v1.17.0] require nunomaduro/collision ^5.4.0 -> found nunomaduro/collision[v5.4.0, ..., v5.11.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.18.0, ..., v1.21.1] require nunomaduro/collision ^5.4.0|^6.0 -> found nunomaduro/collision[v5.4.0, ..., v5.11.0, v6.0.0, ..., v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.21.2, ..., v1.22.1] require nunomaduro/collision ^5.10.0|^6.0 -> found nunomaduro/collision[v5.10.0, v5.11.0, v6.0.0, ..., v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.22.2, ..., v1.22.5] require nunomaduro/collision ^5.11.0|^6.3.0 -> found nunomaduro/collision[v5.11.0, v6.3.0, v6.3.1, v6.3.2, v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.22.6, ..., v1.23.0] require nunomaduro/collision ^5.11.0|^6.4.0 -> found nunomaduro/collision[v5.11.0, v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest v2.6.2 conflicts with phpunit/phpunit >10.2.0.
    - pestphp/pest v2.6.1 conflicts with phpunit/phpunit >10.1.3.
    - pestphp/pest[v2.5.3, ..., v2.6.0] conflict with phpunit/phpunit >10.1.2.
    - pestphp/pest[v2.5.1, ..., v2.5.2] conflict with phpunit/phpunit >10.1.1.
    - pestphp/pest v2.5.0 conflicts with phpunit/phpunit >10.1.0.
    - pestphp/pest[v2.3.0, ..., v2.4.0] conflict with phpunit/phpunit >10.0.19.
    - pestphp/pest[v2.2.1, ..., v2.2.3] conflict with phpunit/phpunit >10.0.18.
    - pestphp/pest[v2.0.2, ..., v2.2.0] conflict with phpunit/phpunit >10.0.17.
    - pestphp/pest v2.0.1 conflicts with phpunit/phpunit >10.0.16.
    - phpunit/phpunit is locked to version 10.2.1 and an update of this package was not requested.
    - Root composer.json requires pestphp/pest * -> satisfiable by pestphp/pest[v0.1.0, ..., v0.3.19, v1.0.0, ..., v1.23.0, v2.0.1, ..., v2.6.2].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require pestphp/pest:*" to figure out if any version is installable, or "composer require pestphp/pest:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

If you see the error above, check the composer require command that you ran. You’ll need the flags displayed above to allow Composer to update your dependencies to satisfy PEST and Laravel.

Configuration

After installation you’ll find you can run the existing Laravel Example tests with the Pest command. This is because Pest is built on top of PHPUnit in a progressive manner.

If you try writing your own test e.g. consider the following:

<?php

it('makes an example request', function () {
    $response = $this->get('/');
    $response->assertStatus(200);
});

You may get an error like the following:

  FAILED  Tests\Feature\ExampleRequestTest > it get an example request                                                                                                                                                                                                 Error
  Call to undefined method Tests\Feature\ExampleRequestTest::get(). Did you forget to use the [uses()] function? Read more at: https://pestphp.com/docs/configuring-tests

  at tests/Feature/ExampleRequestTest.php:4
      1▕ <?php
      2▕
      3▕ it('get an example request', function () {
  ➜   4▕     $response = $this->get('/');
      5▕     $response->assertStatus(200);
      6▕ });
      7▕

  1   tests/Feature/ExampleRequestTest.php:4


  Tests:    2 failed, 2 passed (2 assertions)
  Duration: 0.08s

This is because Pest is not yet configured to use the Laravel TestCase which includes the additional methods such as get, post, actingAs etc.

To solve this we create a new file:

./tests/Pest.php

Add the following into the file

<?php
uses(\Tests\TestCase::class)->in('Feature');
uses(\Tests\TestCase::class)->in('Unit');

This tells Pest to use the Laravel TestCase in your Feature and Unit tests and makes the additional methods available to your Pest tests.

You can now run the test again, and this time it should run without the error

Database Setup (Optional)

Unit tests test blocks of code and so don’t require the Laravel application to start. However, with Feature tests you’ll find that they do boot the Laravel application and everything within – including a database connection. By default, it will connect to whatever you Database Connection is defined as in your .env file which means your tests end up writing to your dev database. This may be fine, but I prefer keeping a separate databases for Dev and Testing.

There’s a number of ways to do this including using SQLite, but I find it’s better to run the same database type as I will be using in production to avoid any unforeseen issues. The easiest way to do this is to create a second database and then configure the connection using a .env.testing file – more information on this is available in the Laravel Docs.

Summary

I hope this guide helps anyone looking for a current installation of Laravel and Pest.

The post HOW TO: SETUP PEST PHP 2 WITH LARAVEL 10+ appeared first on Cube Websites.

The general idea is to use a composer package to interact with Directus. We’ll register it in our AppServiceProvider which means we can call a pre-configured instance anywhere in our app using dependency-injection.

In Directus

• It’s advisable to create a new role for your Laravel Application. To make it easy to track I give it the name ‘laravel-app’
• Create a new user for your Laravel Application and assign it the new Role you just created
• On the Edit User screen, find the ‘Token’ field. Generate a token and make a note of it somewhere

In Laravel

• Now switch to your Laravel app. For this integration, I’m using a composer package from https://github.com/alantiller/directus-php-sdk
• Install the package:

composer require alantiller/directus-php-sdk

• In your .env file add the following:

DIRECTUS_URL=https://directus.example.com
DIRECTUS_TOKEN=-YOURTOKEN

• Replace the Url with your actual Directus URL
• Replace YOURTOKEN with the Token you generated for your Laravel user in Directus
• In config/services.php add the following:

'directus' => [
    'url'   => env('DIRECTUS_URL'),
    'token' => env('DIRECTUS_TOKEN'),
],

In app/providers/AppServiceProvider.php add the following to the register() method

$this->app->singleton(Directus::class, function ($app) {
    $directus = new Directus($app['config']['services']['directus']['url'],'');
    $directus->auth_token($app['config']['services']['directus']['token']);
    return $directus;
});

In your code you’ll be able to now use Directus with the standard dependency injection. You can find examples on how to use the alantiller/directus-php-sdk package on Github.

Example:

php artisan make:command DirectusTest

In the handle method of the generated command:

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;

class DirectusTest extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'directus:test';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Command description';

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle(\Slations\DirectusSdk\Directus $directus)
    {
        dd($directus->users_me());
    }
}

Call the command:

php artisan directus:tset

The output should show you details of the Laravel App user you added on Directus. Once it’s working delete the command.

This is all it takes to have a fully working Directus integration with Laravel. The package does most of the work, but registering it in your AppServiceProvider means you’ll get a connected instance whenever you need to use it instead of having to instantiate it.

Note that this application uses an application token which is tied to a single user. If you need multi-user support then the package supports login so you can authenticate users and use their auth token.

The post HOW TO: Using Laravel with Directus 9 appeared first on Cube Websites.

The project was configured to:

• run on MAMP
• the MAMP host was configured to use SSL
• Laravel 9
• Vite
• InertiaJS

The Problem

When running the default project with yarn run dev and accessing the project in the browser via the hostname configured in MAMP, the hot reload feature was not working and the network and console tabs in Developer Tools were polluted with lots of 404 errors about the failure to connect to the Vite Ping URL e.g. __vite_ping to which it keeps trying to reconnect to.

How to fix

You have to configure Vite to run on https. This can be done in a number of ways, but the easiest is to use the @vitejs/plugin-basic-ssl plugin. It’s really easy to get started:

1. Add the plugin to your project
   • with yarn: yarn add --dev @vitejs/plugin-basic-ssl
   • with npm: npm i @vitejs/plugin-basic-ssl
2. Open the vite.config.js file in your Laravel project
3. Import the plugin at the top of the file:
   • import basicSsl from '@vitejs/plugin-basic-ssl'
4. Enable the plugin using the defineConfig block e.g.

export default {
  plugins: [
    basicSsl()
  ]
}

Note: you might already have other plugins or config options in the defineConfig block, but you just need to make sure you add the called to basicSsl() in the plugins section.

After this when you run your project using yarn run dev it will provide you with a Local URL e.g.

11:15:06 [vite] vite.config.js changed, restarting server...
11:15:06 [vite] server restarted.

  > Local: https://localhost:3000/
  > Network: use `--host` to expose

Open that Local URL in your browser and you’ll receive an SSL warning. Accept the risks to accept the SSL certificate generated by the plugin.

Once that’s done when you visit your application dev URL, you’ll see all the Vite 404 errors have disappeared and you’re left with one neat little log that tells you Vite is now connected.

[vite] connecting... client.ts:16:8
[vite] connected. client.ts:53:14

Hope this helps!

The post HOW TO: Using Laravel with Vite on MAMP appeared first on Cube Websites.