DEV Community: Rafael Beraldo

Installing and using multiple PHP versions with Debian/Ubuntu

Rafael Beraldo — Mon, 22 May 2023 14:32:51 +0000

Ever wondered if there is a nvm-like for PHP?

Not exactly, but we can have multiple PHP versions in our system and switch between them easily, let's see.

Installing multiple versions

The default apt repository only have one PHP version availbale, usually the last stable version. To install others we have to add Ondřej's repository.

sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt update

We can now install individual versions.

PHP 7.4

# add any other extension you may need
sudo apt install -y php7.4-cli php7.4-common php7.4-mysql php7.4-zip php7.4-mbstring php7.4-curl php7.4-xml php7.4-bcmath php8.1-sqlite3

PHP 8.1

# add any other extension you may need
sudo apt install -y php8.1-cli php8.1-common php8.1-mysql php8.1-zip php8.1-mbstring php8.1-curl php8.1-xml php8.1-bcmath php8.1-sqlite3

Switching between versions

Now use the following command to switch between versions.

sudo update-alternatives --config php

Other distros

Fedora also has a similar command: alternatives.

Symfony/Doctrine migrations for multiple databases

Rafael Beraldo — Sat, 06 May 2023 15:07:15 +0000

In Symfony/Doctrine, when running the command php bin/console make:migration it generates the migrations for the current driver only, unfortunately it doesn't generate database-agnostic code.

But it can be easily customized. Let's setup it to generate two migrations, one for MySQL (prod/dev) and one for SQLite (test).

Setup

Setup your MySQL in your .env like you would usually do, but set a MIGRATIONS_PATH="migrations/mysql" property to it.

Then create a .env.test and set:

APP_ENV=test
DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db"
MIGRATIONS_PATH="migrations/sqlite"

In your config/packages/doctrine_migrations.yaml you change default path to get from the env files:

doctrine_migrations:
    migrations_paths:
        'DoctrineMigrations': '%kernel.project_dir%/%env(string:MIGRATIONS_PATH)%'
    enable_profiler: false

Also enable MakerBundle for test env in config/bundles.php:

Symfony\Bundle\MakerBundle\MakerBundle::class => ['dev' => true, 'test' => true],

Running migrations

Now you can work with migrations using:

# for MySQL
php bin/console make:migration
php bin/console doctrine:migration:migrate

# for SQLite
php bin/console make:migration --env=test
php bin/console doctrine:migration:migrate --env=test

Doing this, Symfony will generate migrations for MySQL in migrations/mysql and migrations/sqlite for SQLite.

Creating an API with a modular (folder-by-feature) structure in Laravel

Rafael Beraldo — Sat, 15 Apr 2023 14:00:00 +0000

When creating a Laravel project, you'll find that Laravel by default group folders by archtype. Obviously it does works fine, but for larger projects you get a bit lost with files that are tied by a module coming from all over the places.

The structure I'm aiming for looks like this:

app/Modules/{Module}/
├── {Module}.php (model)
├── {Module}Controller.php
├── {Module}Policy.php
├── {Module}Request.php
├── {Module}Routes.php
├── ...
└── Tests/
    ├── {Module}Factory.php
    ├── {Module}FeatureTest.php
    ├── {Module}Seeder.php
    └── {Module}UnitTest.php

For my use case, seeders are only usable in tests. I do like to keep it with as few subfolders as possible.

I'm not going to implement Controller's methods, the focus of this post is to change the default folder structure for an API.

Installing

Start by creating a new project:

composer create-project laravel/laravel laravel-modular

We'll be using SQLite for this. Create it:

touch database/database.sqlite

Then let's edit our .env (copy from .env.example if it didn't automatically), update these vars:

DB_CONNECTION=sqlite
DB_HOST=database/database.sqlite

Now let's create a namespace for our modules folder, edit your composer.json:

"autoload": {
  "psr-4": {
      "App\\": "app/",
+     "Modules\\": "app/Modules/",
      "Database\\Factories\\": "database/factories/",
      "Database\\Seeders\\": "database/seeders/"
  }
},

You can also put it outside the app folder if you'd like, just update the stuff we're doing here accordingly.

Whenever you update composer's autoload stuff, run this command:

composer dump-autoload

You can now run your app with:

php artisan serve

Creating our module

Let us create a Car module:

mkdir -p app/Modules/Car/Tests
php artisan make:model --all Car

The files will be created at the default Laravel dir structure, move every file to the folder we created:

mv -t app/Modules/Car app/Models/Car.php app/Http/Controllers/CarController.php app/Http/Requests/StoreCarRequest.php app/Policies/CarPolicy.php
mv -t app/Modules/Car/Tests database/factories/CarFactory.php database/seeders/CarSeeder.php

For this tutorial I'll leave migration in the default dir, I prefer to visualize all migrations in chronological order, but you can also move to the module folder if you want.

We also only need a single FormRequest for both store and update:

rm app/Http/Requests/UpdateCarRequest.php
mv app/Modules/Car/StoreCarRequest.php app/Modules/Car/CarRequest.php
# also update class name

After that we have to update every namespace to our new folder, update all files in app/Modules/Car to:

namespace Modules\Car;

And all files in app/Modules/Car/Tests to:

namespace Modules\Car\Tests;

You have to do it for every new module. And if you're puting files inside subfolders you have to adequate those as well. Also fix any import errors you might have -- the first module is always the most time consuming.

Run composer dump-autoload to see if there's any file off from PSR-4.

Setup routes

Let's create a modular route:

touch app/Modules/Car/CarRoutes.php

And update the file:

<?php

use Illuminate\Support\Facades\Route;
use Modules\Car\CarController;

Route::resource('cars', CarController::class);

Route::resource maps index/show/store/update/destroy methods in controller to GET/POST/PUT/DELETE endpoints, see more here: https://laravel.com/docs/10.x/controllers#actions-handled-by-resource-controller

For that to work we need a Service Provider, create one:

php artisan make:provider ModuleServiceProvider

And add a boot method to search routes in our modules (you can do the same thing for migrations if you'd like):

public function boot(): void
{
    // Can also use (**) wildcard if you have subfolders
    foreach (glob(base_path('app/Modules/*')) ?: [] as $dir) {
        $modelClassName = class_basename($dir);
        $path = Str::before($dir, "\\$modelClassName");
        $moduleRouteFile = "$path/$modelClassName" . 'Routes.php';

        if (!file_exists($moduleRouteFile)) continue;

        $this->loadRoutesFrom($moduleRouteFile);
    }
}

And add it to the config/app.php under providers:

App\Providers\ModuleServiceProvider::class

You can now test your route! Should be working.

Setup seeders and factories

Update the migration:

Schema::create('cars', function (Blueprint $table) {
  $table->id();
  $table->string('name');
  $table->timestamps();
});

Update the seeder:

public function run(): void
{
    Car::factory()
        ->count(10)
        ->create();
}

public function run(): void
{
    // Note the leading slash
    $this->call([
        \Modules\Car\Tests\CarSeeder::class
    ]);
}

And the factory:

protected $model = Car::class;

public function definition(): array
{
    return [
        'name' => fake()->name()
    ];
}

Note the protected $model, since we're using a custom file structure, we have to declare it. We also need to add a register method to our Service Provider:

public function register(): void
{
    Factory::guessFactoryNamesUsing(function (string $modelName) {
        $modelClassName = class_basename($modelName);
        $namespace = Str::before($modelName, "\\$modelClassName");
        return "$namespace\\$modelClassName\\Tests\\$modelClassName" . 'Factory';
    });
}

You can now run migration and seeder:

php artisan migrate:fresh --seed

Testing

Last part, let's add some tests, run:

php artisan make:test CarFeatureTest
mv tests/Feature/CarFeatureTest.php app/Modules/Car/Tests/CarFeatureTest.php

Don't forget to update namespaces!

Add a function to the test file:

/** @test */
public function get_cars_should_return_success(): void
{
    $response = $this->get('/cars');
    $response->assertStatus(200);
}

Note the /** @test */ comment, PHPUnit won't find the test if you don't add this comment.

Now we have to update phpunit.xml to discorver our tests:

<testsuites>
    <testsuite name="Unit">
-       <directory suffix="Test.php">./tests/Unit</directory>
+       <directory suffix="UnitTest.php">./app/Modules</directory>
    </testsuite>
    <testsuite name="Feature">
-       <directory suffix="Test.php">./tests/Feature</directory>
+       <directory suffix="FeatureTest.php">./app/Modules</directory>
    </testsuite>
</testsuites>

You have to use UnitTest.php or FeatureTest.php suffix, or change phpunit.xml for your use case.

You can now test:

php artisan test

Conclusion

As you can see, Laravel is very powerful and can handle very well custom structures, with little boilerplate IMO. Unfortunately the php artisan make:* commands won't work correctly within modules, but you can add new commands to make it work for you.

That's it for today, hopefully you learned something!

Repository: https://github.com/rafaberaldo/laravel-modular

Como criar um app Electron usando Vite

Rafael Beraldo — Wed, 06 Jul 2022 23:07:45 +0000

This article is also in english.

Então você quer disponibilizar seu novo aplicativo em Vite usando Electron, mas não quer usar o código pronto dos outros. Vamos entender como funciona e fazer o nosso próprio.

Criar um app Vite

Nós vamos utilizar a estrutura de arquivos do Vite como base do nosso projeto. Inicie com o comando:

$ npm create vite@latest

Depois siga as instruções no terminal. Neste exemplo eu utilizei o preset react-ts. Mas também funciona com Vuejs e provavelmente todos outros.

Adicione o Electron

Agora adicionamos o Electron ao nosso projeto:

$ npm i -D electron@latest

Depois criamos um diretório electron na raíz, e dois arquivos main.js e preload.js. Nossa estrutura de arquivos ficou assim:

project-root/
├── electron/
│   ├── main.js 
│   └── preload.js
├── src/
│   └── ...
├── index.html
├── package.json
├── vite.config.ts
└── ...

Arquivo de entrada do Electron

Electron precisa de um arquivo de entrada para funcionar, vamos editar o electron/main.js:

const { app, BrowserWindow, shell } = require('electron')
const { join } = require('path')

if (!app.requestSingleInstanceLock()) {
  app.quit()
  process.exit(0)
}

let win = null

async function createWindow () {
  win = new BrowserWindow({
    title: 'Main window',
    width: 1024,
    height: 768,
    webPreferences: {
      preload: join(__dirname, '../electron/preload.js'),
      nodeIntegration: true
    }
  })

  if (app.isPackaged) {
    // win.removeMenu()
    win.loadFile(join(__dirname, '../dist/index.html'))
  } else {
    // Vite's dev server
    win.loadURL('http://localhost:5173')
    win.webContents.openDevTools()
  }

app.whenReady().then(createWindow)

app.on('window-all-closed', () => {
  win = null
  if (process.platform !== 'darwin') app.quit()
})

app.on('second-instance', () => {
  if (win) {
    // Focus on the main window if the user tried to open another
    if (win.isMinimized()) win.restore()
    win.focus()
  }
})

app.on('activate', () => {
  const allWindows = BrowserWindow.getAllWindows()
  if (allWindows.length) {
    allWindows[0].focus()
  } else {
    createWindow()
  }
})

O arquivo preload.js vai ficar em branco para esse tutorial. Mas você provavelmente vai utilizar num aplicativo real.

Adicione-o ao package.json:

  ...
+ "main": "electron/main.js",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview",
+   "electron:dev": "electron ."
  },
  ...

Você já pode testar, execute o dev server do Vite num terminal, e do Electron em outro:

# Primeiro terminal
$ npm run dev

# Segundo terminal
$ npm run electron:dev

Repare que estão completamente desacoplados, o HMR funciona normalmente já que só estamos abrindo o dev server do Vite no Electron.

Mas eu quero executar de um único terminal/comando!

Para isso podemos criar um script customizado. Crie um novo arquivo scripts/dev.mjs com:

import { spawn } from 'child_process'
import { createServer } from 'vite'
import electron from 'electron'

const server = await createServer({ configFile: 'vite.config.ts' })

spawn(electron, ['.'], { stdio: 'inherit' }).once('exit', process.exit)

await server.listen()

E atualize o script no package.json:

...
"scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  "preview": "vite preview",
- "electron:dev": "electron ."
+ "electron:dev": "node scripts/dev.mjs"
},
...

Agora você pode abrir ambos dev server num único comando npm run electron:dev.

Note que nesse exemplo não teremos Live Reload nem TypeScript no electron/main.js. Para isso funcionar você pode implementar algo parecido com isso. Na minha opinião não é necessário na maioria dos casos.

Gerando o executável

Nosso dev server está funcionando bem. Agora temos que gerar o executável do app.

Vamos usar o electron-builder. Adicione ao projeto:

$ npm i -D electron-builder

E precisamos de uma arquivo de configuração, crie o electron-builder.yaml na raíz:

# https://www.electron.build/configuration/configuration

appId: your.app.id
asar: true
directories:
  output: release/${version}

files:
- dist
- electron

mac:
  artifactName: "${productName}_${version}.${ext}"
  target:
  - dmg
win:
  target:
  - target: nsis
    arch:
    - x64
  artifactName: "${productName}_${version}.${ext}"
nsis:
  oneClick: false
  perMachine: false
  allowToChangeInstallationDirectory: true
  deleteAppDataOnUninstall: false

Adicione a propriedade base ao arquivo de configuração do Vite vite.config.ts:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  base: './',
  plugins: [react()]
})

Isso adiciona o prefixo ./ em todos assets, necessário para funcionar com o protocolo file:// do Electron.

Agora adicione o script ao package.json:

...
"scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  "preview": "vite preview",
  "electron:dev": "node scripts/dev.mjs",
+ "electron:build": "npm run build && electron-builder"
},
...

Como você pode ver, iremos primeiramente executar a build do Vite, e depois do Electron.

A build do Vite estará localizada no diretório dist, a build do Electron estará localizada no diretório release. Adicione ambos ao .gitignore.

Agora você pode buildar o app com o comando npm run electron:build.

Eeee é isso! Você agora tem seu app Electron usando Vite!

Código completo do tutorial: https://github.com/rafaberaldo/vite-electron

Referências

How to create an Electron app with Vite and minimal boilerplate

Rafael Beraldo — Wed, 06 Jul 2022 18:07:03 +0000

Este artigo também está disponível em português.

So you want to wrap your new Vite application with Electron, but you don't want to use other's boilerplate for it. Let's understand how it works and build our own.

Create a Vite app

We're going to use Vite's preset as the base file structure of our project. Start with the command:

$ npm create vite@latest

Then follow Vite's instructions. In this example I've created the React react-ts preset. But it also works with Vuejs and probably any other.

Add Electron

Now we add Electron to our project.

$ npm i -D electron@latest

Then we create an electron folder in project root, and two files main.js and preload.js. Our folder structure is like this:

project-root/
├── electron/
│   ├── main.js 
│   └── preload.js
├── src/
│   └── ...
├── index.html
├── package.json
├── vite.config.ts
└── ...

Electron entry file

Electron needs an entry file to work, let's edit our electron/main.js:

const { app, BrowserWindow, shell } = require('electron')
const { join } = require('path')

if (!app.requestSingleInstanceLock()) {
  app.quit()
  process.exit(0)
}

let win = null

async function createWindow () {
  win = new BrowserWindow({
    title: 'Main window',
    width: 1024,
    height: 768,
    webPreferences: {
      preload: join(__dirname, '../electron/preload.js'),
      nodeIntegration: true
    }
  })

  if (app.isPackaged) {
    // win.removeMenu()
    win.loadFile(join(__dirname, '../dist/index.html'))
  } else {
    // Vite's dev server
    win.loadURL('http://localhost:5173')
    win.webContents.openDevTools()
  }

app.whenReady().then(createWindow)

app.on('window-all-closed', () => {
  win = null
  if (process.platform !== 'darwin') app.quit()
})

app.on('second-instance', () => {
  if (win) {
    // Focus on the main window if the user tried to open another
    if (win.isMinimized()) win.restore()
    win.focus()
  }
})

app.on('activate', () => {
  const allWindows = BrowserWindow.getAllWindows()
  if (allWindows.length) {
    allWindows[0].focus()
  } else {
    createWindow()
  }
})

The preload.js file will stay blank for this tutorial. But you probably gonna use it in a real world app.

Add it to the package.json:

  ...
+ "main": "electron/main.js",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview",
+   "electron:dev": "electron ."
  },
  ...

You can now test your app, run Vite's dev server in a terminal instance, and Electron in another:

# First instance
$ npm run dev

# Second instance
$ npm run electron:dev

You see that it's completely decoupled, HMR works just fine since we're opening the Vite's dev server URL.

But I want it to run in a single instance/command!

For that we can create a custom script. Create a new file scripts/dev.mjs with:

import { spawn } from 'child_process'
import { createServer } from 'vite'
import electron from 'electron'

const server = await createServer({ configFile: 'vite.config.ts' })

spawn(electron, ['.'], { stdio: 'inherit' }).once('exit', process.exit)

await server.listen()

And update dev script in package.json:

...
"scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  "preview": "vite preview",
- "electron:dev": "electron ."
+ "electron:dev": "node scripts/dev.mjs"
},
...

You can now start dev server with a single npm run electron:dev command.

Note that in our example you won't have live reload nor TypeScript for the electron/main.js. For that you could do something like this. IMO it's not necessary for most cases.

Building the app

Our dev server is working just fine. Now we have to be able to build the app.

We're gonna use electron-builder. Add it to the project:

$ npm i -D electron-builder

And we need a config file, let's create a file electron-builder.yaml in project root:

# https://www.electron.build/configuration/configuration

appId: your.app.id
asar: true
directories:
  output: release/${version}

files:
- dist
- electron

mac:
  artifactName: "${productName}_${version}.${ext}"
  target:
  - dmg
win:
  target:
  - target: nsis
    arch:
    - x64
  artifactName: "${productName}_${version}.${ext}"
nsis:
  oneClick: false
  perMachine: false
  allowToChangeInstallationDirectory: true
  deleteAppDataOnUninstall: false

Add a base property to Vite's config file in vite.config.ts:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  base: './',
  plugins: [react()]
})

This adds a ./ prefix on all assets, necessary to work within Electron's file:// protocol.

Now add a build script to package.json:

...
"scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  "preview": "vite preview",
  "electron:dev": "node scripts/dev.mjs",
+ "electron:build": "npm run build && electron-builder"
},
...

As you can see, we're gonna run Vite's build first, then electron-builder.

Vite's build is located in dist directory, Electron's build is located in release directory. Make sure to add both to .gitignore.

You can now build your app with the npm run electron:build command.

Aaaand voi là! You have your Electron app working with Vite!

Source code of this tutorial: https://github.com/rafaberaldo/vite-electron