DEV Community: Tyler Smith

Alma and Rocky Linux ISOs: DVD vs Boot vs Minimal

Tyler Smith — Mon, 06 Apr 2026 02:43:41 +0000

NOTE: This article was written in April 2026. If you are reading this in the distant future, things have likely changed.

Both AlmaLinux and Rocky Linux come with three ISO options for download: DVD ISO, Boot ISO, and Minimal ISO. Neither the AlmaLinux docs or the Rocky Linux docs do a great job explaining the differences between these ISOs. Posts on the Rocky Linux forms and Reddit elaborate beyond the docs, but still don't do a great job explaining exactly what each ISO contains or when you'd use each.

This article will explain the similarities and differences between the three ISOs, and will provide a recommendation of which ISO you should use.

DVD ISO

The DVD ISO is an ~8gb image that contains all packages for a full offline installation.

By default, the boot ISO will install AlmaLinux or Rocky Linux with server packages and a full GUI via the Gnome desktop environment. To change this, navigate to the Software Selection screen during the installation where you can choose from the following options:

Server with GUI. This installs server packages along with a Gnome desktop environment for easy point-and-click management. It installs the software included with dnf's "Server with GUI" environment group.
Server. This contains all the packages you would expect a distribution to have for managing a server via the CLI. It installs the software included with dnf's "Server" environment group.
Minimal Install. This gives you a bare-bones Linux experience that excludes any packages that aren't absolutely necessary. Everyday commands like nano, vim, and which are excluded, allowing the user to manually install only the software they need when they need it. It installs the software included with dnf's "Minimal Install" environment group.
Custom Operating System. I believe this lets you select the exact packages you want to be installed on the OS. I'm not actually sure how this works because I haven't tried it 🤷‍♂️

To see what dnf groups are available, run the following command on a RHEL-like distribution (Alma, Rocky, CentOS Stream, RHEL).

dnf group list

This will output a list like the following:

Available Environment Groups:
   Server with GUI
   Minimal Install
   Custom Operating System
Installed Environment Groups:
   Server
Installed Groups:
   Container Management
   Headless Management
Available Groups:
   Legacy UNIX Compatibility
   Smart Card Support
   Console Internet Tools
   Development Tools
   .NET Development
   Graphical Administration Tools
   Network Servers
   RPM Development Tools
   Scientific Support
   Security Tools
   System Tools

To see what software is included in a group (for example, the "Minimal Install" environment group), run the command below.

dnf group info "Minimal Install"

This will output the following:

Environment Group: Minimal Install
 Description: Basic functionality.
 Mandatory Groups:
   Core
 Optional Groups:
   Standard

You can drill into these further to see the actual included packages using dnf group info "Core" and dnf group info "Standard".

To install software from a listed group (for example, if you did the "Minimal Install" but want software from "Server"), run the following command:

sudo dnf group install "Server"

You can learn more about DNF groups in OneUptime's article How to Manage Package Groups and Environment Groups with DNF on RHEL.

Boot ISO

The Boot ISO is a ~1gb image that requires an Internet connection during the installation to download packages. It includes all of the same options as the DVD ISO (such as Server with GUI, Server, and Minimal Install within the "Software Selection" installation screen), but since the packages are downloaded during the installation process it allows the ISO image to be significantly smaller.

Minimal ISO

The Minimal ISO is a ~2gb image made for fully offline installation. Unlike the DVD ISO or Boot ISO, the only option on the Software Selection installation screen is Minimal Install (i.e., no Server with GUI, Server, or Custom Operating System options).

Though the Minimal ISO can be installed without a network connection, you will almost certainly need an Internet connection immediately after the installation to install packages like text editors (nano, vim) that make an operating system useful. This makes the promise of a fully offline installation fall short as a result.

Which ISO should you download?

In most cases, the Boot ISO will probably make the most sense: it has the smallest initial download size, and your packages will be up-to-date when you first boot the operating system.

If you were to install via the DVD ISO, you'd need to update almost all of the packages immediately after installation, negating the benefits of the fully offline installation. I'd personally only consider this option if I were installing an operating system on a server that cannot be connected to the Internet.

In most cases, I'd avoid the Minimal ISO unless you want to build the leanest server possible by manually installing only the software that you absolutely need.

Let me know if you found this article helpful. If I got anything wrong, let me know in the comments and I'll correct the article.

OpenStreetMap's software ecosystem and tools

Tyler Smith — Fri, 24 Oct 2025 00:56:15 +0000

OpenStreetMap's Wiki defines OpenStreetMap (OSM) as "a free, editable map of the whole world that is being built by volunteers largely from scratch and released with an open-content license." In some ways, it's like an open source & open data version of Google Maps. Except unlike Google maps, it is not a cohesive product that provides countless capabilities out-of-the-box. OpenStreetMap is a vast ecosystem of open source packages created by small teams of disparate maintainers building pluggable components that are powered by a multitude of technologies and programming languages. While this makes it far less cohesive than a product like Google maps, it makes it more powerful and customizable.

This article will look at various pieces of the OpenStreetMap ecosystem. OSM information is spread across many sites and hard-to-find links: this is an attempt to consolidate much of that information in one place.

openstreetmap.org

OpenStreetMap's website allows users to view & edit OpenStreetMap data. You can think of it as Wikipedia for maps. Built on top of Ruby on Rails, the site is the central repository for OpenStreetMap data that all other tools in the OSM ecosystem rely upon. The website is also a miniature showcase for OSM capabilities like map rendering, theming (available in the "layers" panel), and directions (which allows the user to pick from multiple routing services).

Most users will not consume OpenStreetMap's capabilities through its website: the data provided by the website is intended to be consumed by application developers building their own map-based applications.

OpenStreetMap data

OpenStreetMap's user-contributed data is the core of its ecosystem. With almost all of the software surrounding OSM being composed of interchangeable pieces, the data is OSM's defining quality.

The planet.openstreetmap.org subdomain provides weekly exports of the entire planet's OpenStreetMap data. It is provided as both compressed XML files and a custom Protobuf format which uses a .osm.pbf extension. At the time of writing, the compressed XML files are a little over 150gb, and they uncompress to over 2 TB according to the Wiki. The .osm.pbf Protobuf files are a little more than half the size, with the most recent being a little more than 80gb at the time of writing. In addition to being smaller, .osm.pbf can also be processed faster so they're generally the more desirable format.

Because the complete Planet dataset is so large, OSM also offers much smaller weekly changesets that can be applied to an existing planet export on a rolling basis to keep it in sync.

The exported data is typically imported into a PostgreSQL database with the PostGIS extension enabled. The data is typically imported into PostgreSQL using osm2pgsql. The full Planet data can exceed a terabyte when imported into Postgres (source, source, source), and the import process can take hours or days depending on your hardware, Postgres optimizations, and import flags. OSM's Osmosis tool can shrink the size of the data by extracting only the data that you're interested in, such as data inside of a bounding box, or extracting only the speed cameras. The OSM Wiki contains a list of other data extraction tools to reduce the dataset to the things a developer is interested in.

The most straight forward way to keep a dataset small & an import fast is to download a dataset of a single geographic area. OpenStreetMap's does not provide geographic extracts, but sites like download.openstreetmap.fr, Geofabrik, and BBBike offer regularly-updated geographic extracts. You can find more extract sources on the OSM wiki's Planet.osm page, Processed data providers page, and Switch2OSM's Serving Tiles page.

Rendering an OpenStreetMap on the web

To view an OSM map, you need a map library and a tile server. Map libraries create interactive maps using tiles provided by a tile server. Tile servers take OpenStreetMap data and render pieces of a map into individual squares that can be used by a map library.

Map libraries

Unlike commercial products like Google Maps, OpenStreetMap does not have an "official" map library that you are required to use. Among the most popular OSM map libraries for the web are Leaflet, which is the default map viewer on openstreetmap.org, and OpenLayers, which is considered more powerful but has a steeper learning curve. Alternatives like MapLibre have SDKs for web, Android, and iOS. Other popular map libraries can be found on the OSM wiki and Awesome OSM.

Tiles consumed by these map libraries can be raster tiles (images made of pixels), or vector tiles (comprised of geometries and metadata). While raster tiles can generally be used by any map library that supports them (like Leaflet), there are competing schemas for vector tiles, and a vector map library might not support all vector tile schemas.

Raster tiles

OpenStreetMap officially maintains 2 first-party raster tile server packages called mod_tile and Tirex. The rendering for these tools is powered by the open source Mapnik map generation library. Mapnik requires styles to be provided via an XML config, and a CSS-like language called CartoCSS was created by Mapbox that compiles down to Mapnik configs to make building these XML configs easier. CartoCSS was phased out by Mapbox starting in 2016 in favor of their vector tiles. Despite CartoCSS not receiving a commit since 2020 and the GitHub project being archived in 2024, the OpenStreetMap website still uses it for defining its Mapnik styles. A project called openstreetmap-carto maintains the stylesheets for the standard map layer on openstreetmap.org. To see more about how these pieces fit together, check the component overview page on the OSM wiki.

Despite being first-party, these components are not required and can be substituted with various open source packages (mbtileserver, TileServer GL, etc.) or commercial tile servers as a service (Mapbox, Stadia Maps, etc.). As long as raster tile servers follow the filename and URL path conventions, they are interchangeable. You can find additional tile server packages on the OSM Wiki.

OpenStreetMap provides a free-of-charge raster tile server at https://tile.openstreetmap.org/ that is ideal for developers to learn to build maps without having to set up their own tile server or pay a third-party tile provider. To keep it free for everyone, users must abide by its tile usage policy which prohibits bulk downloads of tiles and no-cache headers. Since this tile server provides no uptime guarantees, commercial apps should strongly consider using a paid raster tile provider or hosting their own raster tile server. If you are considering hosting your own tile server for a heavy production workload, the OSM wiki has the specs that they require for running their own production tiling servers. It's worth noting that not every single tile needs to be pre-rendered by the tile server: a recently removed Tile disk usage page on the Wiki estimates that pre-rendering every tile would take up 54tb, and less than 2% of all total tiles are actually viewed.

Vector tiles

OpenStreetMap does not officially maintain any first-party vector tile server packages, but several open source packages exist for generating and serving tiles (tilemaker, mbtileserver, Martin, etc.), along with several tile providers as a service. Vector Tiles were a project that originally came out of commercial map provider Mapbox to enable new map capabilities, like rotating a map while maintaining the text orientation. You can read more about the history of vector maps on daniel-j-h's blog post.

Mapbox created a format called Mapbox Vector Tiles (MVT) based on Google's Protobuf. It is the defacto industry standard for vector tiles and has a .mtv extension. These tiles can have different schemas (data included inside of the MVT tile). If MVT is like a CSV file, schemas are like the column names. Popular vector tile schemas include Shortbread and OpenMapTiles.

OpenStreetMap provides a free-of-charge Shortbread vector tile server at https://vector.openstreetmap.org that is ideal for developers to learn to build maps without having to set up their own tile server or pay a third-party tile provider. Like OSM's raster tile server, users must abide by its tile usage policy which prohibits bulk downloads of tiles and no-cache headers. You can see a demo of their vector tile server here.

To learn more about vector tiles, visit the OSM wiki's Vector tiles page.

Static maps

Alternatively, it is possible to render a static map to an image instead of using a map library for an interactive map (similar to Google Maps Static API). The OSM wiki static map images page provides a list of services and software packages to enable this functionality, but if you're already using Mapnik, it may be simplest to accomplish this using its Node or Python bindings.

To learn more about rendering raster, vector, or static maps, visit the OSM wiki's Rendering page.

Geocoding

Geocoding is the process of taking the name or address of a place and returning its longitude and latitude.

OpenStreetMap maintains a Python-based open source project called Nominatim for geocoding with OpenStreetMap. Nominatim uses osm2pgsql to import its data. Unfortunately, tile servers and Nominatim cannot share a database: their database schemas are incompatible. Nominatim also supports reverse geocoding, which takes a longitude and latitude and returns what is at that location.

OpenStreetMap runs a free-to-use Nominatim server, but the permitted usage is restricted: an absolute maximum of 1 request per second. Additionally, clients repeatedly sending the same query may be blocked. Because of this, you may want to consider self-hosting or using one of the commercial providers listed on the OSM wiki's Geocoding page.

Routing

Routing creates directions to get from point A to point B, much like Google Maps' directions. There are different routing tools for cars, bikes, and more.

While OpenStreetMap does not maintain any first-party routing tools, its website features OSRM, GraphHopper, and Valhalla. Additional routing software can be found on the OSM wiki's Routing page.

OpenStreetMap's license

Disclaimer: I am not a lawyer and this is not legal advice. The following section is my personal understanding of the ODbL, which may be incorrect. Do not take my interpretation as a statement of fact.

The OpenStreetMap data is covered by the Open Data Commons Open Database License (ODbL). From my reading and limited understanding, it feels like the GPL for data, but with slightly less viral copy-left enforcement. You can use the data for any purpose (including commercial), but you must attribute the source. You may create a Derivative Database by modifying or extracting data, but you must make the Derivative Database available, and that database must attribute the original source. However, things created with the Database or Derivative Database (Produced Works) may be licensed under different terms than the OBbL as long as the previously listed obligations have been met.

An interesting part of the ODbL is the idea of a Collective Database, where the data from the ODbL database is unmodified but combined with data from other independent datasets that are assembled into a collective whole. A Collective Database is not considered a Derivative Database, therefore included non-OBdL datasets that are used in conjunction with OBdL Databases are not subject to the requirements of the OBdL. We can see this in action in Apple Maps' data acknowledgement page, where they list OpenStreetMap contributors first, then list many commercial and listings below.

The Open Data Commons site includes a human readable summary of the ODbL 1.0 license, but I'd recommend reading the full license and consulting a lawyer if you have questions. Certainly take everything I've said with a grain of salt.

Attribution requirements

Things created with OpenStreetMap must attribute OpenStreetMap and make clear that the data is covered by the OBdL license. For maps, this is typically done by putting a hyperlink that says OpenStreetMap in the map's bottom right hand corner and linking to the OSM Copyright page, which has information about OpenStreetMap’s data sources as well as the ODbL. The OpenStreetMap Foundation has a Licence/Attribution Guidelines page on their website that discusses guidelines for other Produced Works such as static maps and routing engines.

Where to start

The best place to start your journey with OpenStreetMap development is the Switch2OSM website. It discusses the fundamentals of OSM in much simpler terms than this article, and has instructions for getting started with tiles using Leaflet, OpenLayers, and MapLibre. Switch2OSM also has tutorials for setting up your own tile server on Docker, Debian, and Ubuntu, but for many use cases developers can use OpenStreetMap's free tile servers and not have to set up their own.

I hope you found this post helpful. Please comment if you find incorrect information: I've been exploring the OpenStreetMap ecosystem for about a week so my understanding is limited. This post was an attempt to organize everything I've learned and keep track of links to every page I found helpful in shaping my understanding OSM.

Absolute paths for assets in iOS & Android Cordova apps

Tyler Smith — Fri, 31 Jan 2025 04:36:23 +0000

There's an abundance of outdated information that states you can only use relative paths for assets in Cordova mobile apps. That information is incorrect: you can use absolute paths for assets in Cordova by configuring the scheme and hostname within config.xml. These configuration settings have been in Cordova for several years, and they are mentioned in the June 2020 Cordova version 6 release notes.

Here's what the Cordova documentation says about scheme and hostname:

Attributes Description

Attributes	Description
scheme `String` Android & iOS	Default: Android: `https` iOS: not defined, but falls back to `app` if the value is invalid. Allowed values: Android: `http` or `https` iOS: Any non-reserved schemes. (Example Reserved Schemes) This property contains the scheme which your app content is served from.
hostname `String` Android & iOS	Default: `localhost` This property contains the hostname which the app content is served from. If the preference `scheme` is not defined for iOS, the `hostname` value will be ignored.

scheme
String
Android & iOS

Default:

Android: https
iOS: not defined, but falls back to app if the value is invalid.

Allowed values:

Android: http or https
iOS: Any non-reserved schemes. (Example Reserved Schemes)

This property contains the scheme which your app content is served from.

hostname
String
Android & iOS Default: localhost

This property contains the hostname which the app content is served from.

If the preference scheme is not defined for iOS, the hostname value will be ignored.

Using `scheme` and `hostname` within `config.xml`

You can set the scheme and hostname preferences within the respective platform blocks.

<?xml version="1.0" encoding="UTF-8"?>
<widget
    xmlns="http://www.w3.org/ns/widgets"
    xmlns:cdv="http://cordova.apache.org/ns/1.0"
    id="io.cordova.hellocordova"
    version="1.0.0"
>
    <platform name="android">
        <preference name="scheme" value="https" />
        <preference name="hostname" value="localhost" />
    </platform>

    <platform name="ios">
        <preference name="scheme" value="app" />
        <preference name="hostname" value="localhost" />
    </platform>

    <!-- Other config settings... -->
</widget>

With this, you can load your assets using absolute paths:

<!-- stylesheet -->
<link rel="stylesheet" href="/assets/style.css" />

<!-- script -->
<script src="/assets/app.js"></script>

<!-- image -->
<img alt="DEV example" src="/assets/example.png">

Compatibility

With the browser platform, absolute paths are supported by the web platform itself: schemes and hostnames are built-in. However, Cordova's Electron target does not support scheme or hostname, so Electron Cordova apps must load assets using relative paths.

Did Cordova always work like this?

Cordova has not always supported scheme and hostname on all mobile platforms, but it was added to better support CORS and simplify asset loading. Before these settings were available, Cordova used file:// paths like the one below:

file:///Users/tyler/Library/Developer/CoreSimulator/Devices/AFB24668-7341-4D77-9C7D-D75EF6FF602D/data/Containers/Bundle/Application/435E23A3-9004-4160-87F3-13A3895F734C/HelloWorld.app/www/index.html

With the scheme and hostname set, the URL becomes much shorter:

app://localhost/index.html

Using the file path

If you would like to get an asset's file:// path, the first-party cordova-plugin-file plugin allows you to access the absolute file path from within the application's JavaScript:

let img = cordova.file.applicationDirectory + 'www/assets/img.png';

Other resources

To learn more about Cordova's approach to handling locally hosted content, check out this GitHub issue on the W3C WebView Community Group on the usage-and-challenges repo.

I hope this post helped you. Please drop a comment if I got anything wrong and I'll get it updated.

How to hold apps for manual release on Google Play Console and Apple's App Store Connect

Tyler Smith — Tue, 28 Jan 2025 03:09:09 +0000

Sometimes you want to submit mobile apps for review, but you want to manually control when they are released. This can be helpful if you have a new feature that you want to release on Android and iOS around the same time, but your app doesn't have any kind of feature flagging. This article will walk you through how to do that in both Google Play Console and App Store Connect.

NOTE: This article was written in January 2025. If you are reading this article in the distant future, details have likely changed.

Google Play Console (Android)

On Google Play Console, manual releases (called "managed publishing" on the platform) is an app-level setting that applies to all releases for that app.

After selecting the app in Google Play Console, navigate to Publishing overview in the sidebar, then click Turn on managed publishing. Confirm the changes in the modal, then click Save. This will hold all approved app changes until the developer manually releases them.

App Store Connect (iOS)

On App Store Connect, manual releases is a setting that is configured on each release version of the app.

After creating a new version of the app, scroll down to the section titled App Store Version Release and select Manually release this version. This will hold that specific approved app version until the developer manually releases it.

Hopefully this article helps you as you build your mobile applications. If at all possible, opt for implementing feature flagging instead of manually releasing your apps.

Implementing & testing Socialite authentication in Laravel

Tyler Smith — Tue, 31 Dec 2024 11:52:52 +0000

Laravel Socialite is a first-party Laravel package that helps developers implement OAuth & OAuth2 social authentication in their applications. It has built-in support for Facebook, Twitter, Google, LinkedIn, GitHub, GitLab, and Bitbucket. Socialite can support other providers through community packages.

This post will:

Explain what Socialite does and does not do.
Show how to integrate Google authentication into a new Laravel project via Socialite.
Show an example of testing Socialite.

TLDR: you can view the completed project on my GitHub. Take a look at it if you would rather just read the completed code.

What does Laravel Socialite do and not do?

Socialite is a small package, with its main API primarily consisting of two main methods:

Socialite::driver($authProvider)->redirect() will redirect the user to the specified auth provider, passing any necessary information to the provider via URL parameters.
Socialite::driver($authProvider)->user() retrieves user data passed back from the auth provider and makes it available to the endpoint.

There are additional support methods for settings scopes and optional parameters. You can read about them in the Socialite documentation.

Socialite does not do the following, leaving the implementation of these items up to the developer:

❌ Create database tables or columns needed to store social auth data.
❌ Create users that don't exist during the authentication process.
❌ Authenticate the user after a successful OAuth flow.
❌ Refresh OAuth tokens.

Prerequisites: creating a Google Cloud project

We will set up a small Socialite project that allows the user to authenticate via Google. To do that, you must create a Google app.

First create a new Google Cloud project, then configure an OAuth consent screen for the project. Set the user type to external, then enable the following scopes:

.../auth/userinfo.email
.../auth/userinfo.profile

After configuring the consent screen, create an OAuth 2.0 Client ID by visiting the Google Cloud Credentials Page. Hold on to the client ID and client secret: we will use them later in the project.

Setting up a minimal Laravel project with Socialite

Create a new Laravel project:

laravel new socialite-tests

Select the following options from the installer:

 ┌ Would you like to install a starter kit? ────────────────────┐
 │ No starter kit                                               │
 └──────────────────────────────────────────────────────────────┘

 ┌ Which testing framework do you prefer? ──────────────────────┐
 │ Pest                                                         │
 └──────────────────────────────────────────────────────────────┘

 ┌ Which database will your application use? ───────────────────┐
 │ SQLite                                                       │
 └──────────────────────────────────────────────────────────────┘

 ┌ Would you like to run the default database migrations? ──────┐
 │ Yes                                                          │
 └──────────────────────────────────────────────────────────────┘

Change into the project directory and install Socialite.

cd socialite-tests
composer require laravel/socialite

Create a new migration.

php artisan make:migration add_socialite_fields_to_users

Place the following code in the newly created migration file in database/migrations:

<?php
// database/migrations/2024_12_31_075619_add_socialite_fields_to_users.php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     */
    public function up(): void
    {
        Schema::table('users', function (Blueprint $table) {
            $table->string('google_id')->default('');
            $table->string('google_token')->default('');
            $table->string('google_refresh_token')->default('');

            // If your app allows both password and social logins, you
            // MUST validate that the password is not blank during login.
            // If you do not, an attacker could gain access to an account
            // that uses social login by only knowing the email.
            $table->string('password')->nullable()->change();
        });
    }

    /**
     * Reverse the migrations.
     */
    public function down(): void
    {
        Schema::table('users', function (Blueprint $table) {
            $table->dropColumn('google_id');
            $table->dropColumn('google_token');
            $table->dropColumn('google_refresh_token');
            $table->string('password')->nullable(false)->change();
        });
    }
};

This migration adds fields that will be provided by Socialite when the user successfully authenticates. In our implementation we're adding these fields directly onto the user table for simplicity. If you wanted to support more providers than Google, you may want to create a separate table that could store multiple providers per user.

We're setting the password to be nullable because a user will never set a password if they only authenticate via Google. If your app permits social authentication and password authentication, you must validate that the password is not blank or null when a user attempts to login via a password.

Run the migration.

php artisan migrate

In config/services.php, add the following block of code to the end of the services array. You can find a full list of valid Socialite service names in the configuration docs.

// config/services.php

'google' => [
    'client_id' => env('GOOGLE_CLIENT_ID'),
    'client_secret' => env('GOOGLE_CLIENT_SECRET'),
    'redirect' => '/auth/google/callback',
],

Add the following to .env, using the credentials from your Google app that you created in the "prerequisites" section.

# .env

GOOGLE_CLIENT_ID="your-google-client-id"
GOOGLE_CLIENT_SECRET="your-google-client-secret"

Replace the contents of routes/web.php with the following code.

<?php
// routes/web.php

use App\Models\User;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Route;
use Laravel\Socialite\Facades\Socialite;
use Laravel\Socialite\Two\InvalidStateException;
use Laravel\Socialite\Two\User as OAuth2User;

Route::get('/', function () {
    return view('welcome');
});

Route::get('/auth/google/redirect', function () {
    return Socialite::driver('google')->redirect();
});

Route::get('/auth/google/callback', function () {
    try {
        /** @var OAuth2User $google_user */
        $google_user = Socialite::driver('google')->user();
    } catch (InvalidStateException $exception) {
        abort(400, $exception->getMessage());
    }

    $user = User::updateOrCreate([
        'email' => $google_user->email,
    ], [
        'google_id' => $google_user->id,
        'name' => $google_user->name,
        'google_token' => $google_user->token,
        'google_refresh_token' => $google_user->refreshToken,
    ]);

    Auth::login($user);
    return redirect('/');
});

Route::get('/auth/logout', function () {
    Auth::logout();
    return redirect('/');
});

The new code in this file implements the routes for:

Redirecting to Google for social login with the appropriate information.
Handling the callback from Google. This route creates or updates a user upon login, then authenticates them, and redirects them to the homepage.
Logging out an authenticated user.

Finally, replace the contents of resources/views/welcome.php with the following markup.

<!-- resources/views/welcome.php -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Laravel Socialite Testing Example</title>
</head>
<body>
    <h1>Laravel Socialite Testing Example</h1>
    @if (auth()->check())
        <p>User is authenticated.</p>
        <p>Name: {{ auth()->user()->name }}</p>
        <p>Email: {{ auth()->user()->email }}</p>
        <p><a href="/auth/logout">Logout</a></p>
    @else
        <p>User is not authenticated.</p>
        <p>
            <a href="/auth/google/redirect">Login with Google</a>
        </p>
    @endif
</body>
</html>

With this completed, we can manually test the app by running the development server.

php artisan serve

When you click the Login with Google link, you should go through the OAuth2 flow and be redirected to the homepage where you can see information about the newly created user from Google.

Testing Socialite with Pest

Our manual tests work, but we'd like automated tests to verify that we don't accidentally break this functionality in the future.

We can create a new test file with the following command.

php artisan make:test AuthRoutesTest

Replace the contents of the newly created tests/Feature/AuthRoutesTest.php with the following.

<?php
// tests/Feature/AuthRoutesTest.php

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Laravel\Socialite\Contracts\Provider as SocialiteProvider;
use Laravel\Socialite\Facades\Socialite;
use Laravel\Socialite\Two\User as OAuth2User;
use Illuminate\Support\Facades\Auth;

use function Pest\Laravel\assertAuthenticated;
use function Pest\Laravel\assertGuest;
use function Pest\Laravel\get;

uses(RefreshDatabase::class);

describe('authentication routes', function () {
    it('redirects login route to correct Google URL', function () {
        $response = get('/auth/google/redirect');

        $redirect_url = $response->getTargetUrl();
        $parsed_query = []; // passed by reference to parse_str()
        parse_str(parse_url($redirect_url)['query'] ?? '', $parsed_query);

        $response->assertStatus(302);
        expect($redirect_url)->toStartWith(
            'https://accounts.google.com/o/oauth2/auth'
        );
        expect($parsed_query)->toHaveKeys([
            'client_id',
            'redirect_uri',
            'scope',
            'response_type',
            'state'
        ]);
    });

    it('creates and authenticates a user that does not yet exist', function () {
        $oauth_user = new OAuth2User();
        $oauth_user->id = '12345';
        $oauth_user->name = 'Tyler Smith';
        $oauth_user->email = 'tyler.smith@example.com';
        $oauth_user->token = '123456789abcdef';
        $oauth_user->refreshToken = '123456789abcdef';

        $mock_provider = Mockery::mock(SocialiteProvider::class);
        $mock_provider->shouldReceive('user')->andReturn($oauth_user);
        Socialite::shouldReceive('driver')
            ->with('google')
            ->andReturn($mock_provider);

        get('/auth/google/callback');

        assertAuthenticated();
        expect(User::count())->toBe(1);
        expect(Auth::user()->email)->toBe($oauth_user->email);
    });

    it('authenticates an existing user', function () {
        $oauth_user = new OAuth2User();
        $oauth_user->id = '12345';
        $oauth_user->name = 'Tyler Smith';
        $oauth_user->email = 'tyler.smith@example.com';
        $oauth_user->token = '123456789abcdef';
        $oauth_user->refreshToken = '123456789abcdef';

        $app_user = User::factory()->create([
            'email' => $oauth_user->email,
        ]);

        $mock_provider = Mockery::mock(SocialiteProvider::class);
        $mock_provider->shouldReceive('user')->andReturn($oauth_user);
        Socialite::shouldReceive('driver')
            ->with('google')
            ->andReturn($mock_provider);

        get('/auth/google/callback');

        assertAuthenticated();
        expect(User::count())->toBe(1);
        expect(Auth::id())->toBe($app_user->id);
    });

    it('redirects authenticated user to the homepage', function () {
        $oauth_user = new OAuth2User();
        $oauth_user->id = '12345';
        $oauth_user->name = 'Tyler Smith';
        $oauth_user->email = 'tyler.smith@example.com';
        $oauth_user->token = '123456789abcdef';
        $oauth_user->refreshToken = '123456789abcdef';

        $mock_provider = Mockery::mock(SocialiteProvider::class);
        $mock_provider->shouldReceive('user')->andReturn($oauth_user);
        Socialite::shouldReceive('driver')
            ->with('google')
            ->andReturn($mock_provider);

        $response = get('/auth/google/callback');

        assertAuthenticated();
        $response->assertRedirect('/');
    });

    it('returns 400 when the oauth callback url is requested directly', function () {
        $response = get('/auth/google/callback');

        $response->assertStatus(400);
        assertGuest();
    });
});

How the tests work

When testing the redirect route, we test that Socialite redirects to the correct URL and passes the correct URL parameters.

When testing the callback routes, we mock Socialite. Mocking isn't my favorite option: in an ideal world, we could swap out Socialite for another OAuth2 implementation and our tests would still work. However, there's not a straight forward way to hook into the authorization grant request that Socialite sends to garnish the access token. Because of this, mocking is the most practical approach to testing Socialite.

Fluent APIs are tedious to mock via Mockery: you must start from the end call and work your way backwards.

Here is the Socialite method that our callback endpoint invokes.

Socialite::driver('google')->user();

Here is how that must be mocked via Mockery:

// Mock ->user();
$mock_provider = Mockery::mock(SocialiteProvider::class);
$mock_provider->shouldReceive('user')->andReturn($oauth_user);

// Mock Socialite::driver('google')
Socialite::shouldReceive('driver')
    ->with('google')
    ->andReturn($mock_provider);

Finally, we have a test to ensure that navigating directly to the callback URL outside of the OAuth flow returns a 400 status code. We wrapped the call to Socialite::driver('google')->user() in the callback endpoint within a try/catch block. If we hadn't wrapped the Socialite call in a try/catch block and someone typed the callback URL into their browser, the endpoint would throw an exception with an HTTP 500 status code. If your team has monitoring set up for 500 status codes, that could cause someone to get paged in the middle of the night.

Wrapping up

This is a minimal integration, and there's a lot more that could be implemented. If we were implementing an integration with a social provider where the user's email could change, this implementation wouldn't work since it matches against the email address. If the user could change their email address within our app, this implementation also wouldn't work for the same reason. However, now that you've seen how to test Socialite, you could write tests for these scenarios and modify the underlying implementation so that they pass.

I read a lot of blog articles and forum posts about Socialite before I understood how to build my own implementation, how to test it, and what I should think about. I'd like to acknowledge some of those here.

Read those if you're interested in digging deeper. Also, let me know if you'd be interested in a part 2 of this post where I dig into handling multiple social providers, handling when a user changes their email address, or handling refresh tokens.

12 things I learned about hosting serverless sites on Cloudflare

Tyler Smith — Sun, 29 Dec 2024 21:18:54 +0000

I spent years avoiding "serverless" architecture. Deploying my applications to a server that I configured is a point of personal pride. And I do that... sometimes. But more often than not, I stop myself from building personal projects because I don't want to manage yet another server, and I absolutely don't want to pay for hosting.

Cloudflare's Developer Platform has a generous free-tier for serverless apps, a relational database built on top of SQLite, and a simple path to deployment. I already use Cloudflare for DNS on most of my projects, so I decided I'd give their platform a shot.

This post will cover 12 things I learned about building and deploying serverless sites using Cloudflare. The post was written in December 2024, so if you're reading this from the distant future some details may have changed.

1. Cloudflare has two competing offerings for building serverless websites: Workers and Pages

Cloudflare Workers is a serverless functions platform capable of running code and serving static assets. Cloudflare Pages is a static site platform that is capable of running serverless functions.

The differences between these two offerings is subtle because they have such similar capabilities. Each has its quirks though, and some of those will be discussed later in this post.

If you're like me, you'll try both and never be sure if you picked the right one for any given project.

September 2025 update: Cloudflare's Pages homepage now has a banner at the top encouraging new users to choose Workers over Pages.

2. If you want to put your Pages or Workers site on an apex domain, Cloudflare must manage its DNS

If you owned the domain example.com and you wanted https://example.com to point to your Cloudflare-hosted website, the DNS for that domain must be managed by Cloudflare.

You can point to Cloudflare sites on subdomains like www.example.com or blog.example.com without Cloudflare managing that domain's DNS. However, Cloudflare must manage a domain's DNS in order to point the apex domain (a domain without a subdomain) to a Workers or Pages site.

3. If you know that you're going to deploy a site to Cloudflare, it's worth using Cloudflare's tools to create it

Cloudflare has documentation for hosting various frameworks on both Workers and Pages. Each guide has two sets of instructions:

How to set up a new project in your framework of choice to run on Cloudflare by using npm create cloudflare ....
How to retrofit an existing project in your framework of choice to run on Cloudflare.

Having tried both, I'd recommend using npm cloudflare create if you know that you're going to deploy your site to Cloudflare. It gives you everything you need out of the box while leaving most of the framework scaffolding untouched.

4. When you scaffold a site using `npm cloudflare create`, you can run local versions of Cloudflare services

When I began building an Astro site that needed Cloudflare D1 to store form submissions, I wasn't yet sure if I could use D1 locally.

It turns out that when I scaffolded Astro using npm create cloudflare, some kind of local emulation for Cloudflare's services was installed into my site. This enables the site to run Cloudflare's D1, R2, and KV locally. However, these services must be added to wrangler.toml before they can be used.

Since I've only deployed Astro to Cloudflare, I'm not 100% certain that every framework works this way. That said, I'd guess that any framework with a Cloudflare adapter installed gets access to these tools regardless of how it was created.

5. To use a Cloudflare service locally, that service must have an ID in `wrangler.toml`

Before I was certain that I wanted to use Cloudflare's Developer Platform, I wanted to set up a local D1 instance for experimentation. I added the following to my wrangler.toml file:

[[d1_databases]]
binding = "MY_DB"
database_name = "my-database"

When I started my site with npm run dev, it crashed with the following error:

Processing wrangler.toml configuration:
  - "d1_databases[0]" bindings must have a "database_id" field but got {"binding":"MY_DB","database_name":"my-database"}.

It turns out that databases must have a database_id in wrangler.toml in order to run locally. However, the ID doesn't necessarily need to be a valid ID of a D1 database that exists on Cloudflare. You can set database_id to any non-blank string and the site will boot without issue:

[[d1_databases]]
binding = "MY_DB"
database_name = "my-database"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

After that, you can create your first migration with the following command, replacing <DATABASE_NAME> with the name of the database defined in wrangler.toml:

npx wrangler d1 migrations create <DATABASE_NAME> <MIGRATION_NAME>

After you've filled in your generated migration file with the SQL statements that you want executed, you can run the migration on your local database with the command below. You must include the --local flag to ensure it runs against the local database instead.

npx wrangler d1 migrations apply <DATABASE_NAME> --local

Once created, you can find the SQLite database file from the main project directory at .wrangler/state/v3/d1/<FILENAME>.sqlite. The filename will be long and machine generated, but it will end with the .sqlite extension. You can use a client like TablePlus to connect to it.

When it comes time to deploy your site, you'll want to create a real D1 database on Cloudflare and replace database_id in wrangler.toml with the ID of the real production database. You can create a database through Cloudflare's UI, or by running the following wrangler command:

npx wrangler d1 create <DATABASE_NAME>

When the command runs, it will give you toml to copy and paste into your wrangler.toml file.

NOTE: If you know that you're going to deploy a D1 database to Cloudflare, it's worth creating the production database at the start of a project and putting its info into wrangler.toml. Cloudflare D1 is charged by rows written, rows read, and storage instead of a monthly fee. The free tier is generous, and creating an empty database costs nothing.

6. Compatibility with Node.js isn't 100%

Cloudflare Workers and Pages don't provide the Node runtime APIs by default. You can enable some of Node's runtime APIs by setting the following top-level configuration option in wrangler.toml:

compatibility_flags = ["nodejs_compat"]

Unfortunately, this only enables a small subset of Node's runtime APIs. I wasn't able to use Nodemailer in one of my projects because it relied on Node features that aren't available in Cloudflare workers. This isn't just limited to Nodemailer: there is no way to do SMTP mailing with any library from a Cloudflare Worker: the protocol requires Node features that Workers don't implement–even when Node compatibility is enabled. I had to rewrite my email code to use Mailgun's API directly.

Hosting on Cloudflare means that you will occasionally run into compatibility issues. This is the cost of free hosting.

7. Cloudflare Pages do not allow you to set production environment variables in the Cloudflare UI

When deploying to Cloudflare pages, you must set any environment variables that will be used by the site in wrangler.toml. You may set secrets in the Cloudflare UI, but secrets cannot be retrieved in the UI after they are written: only replaced.

This limitation can be frustrating if your project has data that's not quite a secret but you'd rather keep out of a public repository. For example, a site I built notifies a list of email addresses when a user submits a form. The recipients email addresses aren't quite a secret, but I don't want to commit them to version control. I'd also like to be able to easily check what email addresses currently receive notifications.

If I deploy this site to Pages, I'll have to set the email recipient list in one of the following ways:

Put the recipient email addresses in my public repo where anyone could see them. While this is the simplest approach, the notification recipients might prefer to keep their email addresses private.
Set the recipient email addresses as a secret in the Cloudflare UI. If I did this, I would not be able to check what emails are currently in the recipient list. Secrets cannot be retrieved via the Cloudflare UI after they are written: only replaced.
Store recipient email addresses in D1 or KV. This feels like a lot of work for something that should be simple, but it might be the best option.

At the time of writing, Cloudflare Workers do not have this limitation. In Workers, you can set environment variables from within Cloudflare's UI.

8. Worker environment variables set in Cloudflare's UI will be overwritten by variables in `wrangler.toml`

With Workers, you can set environment variables in the Cloudflare UI. However, the default behavior is to overwrite them with variables set in wrangler.toml on each deployment.

To prevent wrangler.toml from overwriting your variables on deploy, set the following top-level configuration option in wrangler.toml:

keep_vars = true

I wouldn't be surprised if keep_vars disappears at some point in the future. Cloudflare appears to be moving towards configuration-as-code, and having environment variables stored outside of Git is at odds with this approach.

9. Environment variables aren't actually environment variables

In Cloudflare Workers, environment variables that are set via [vars] in wrangler.toml or in the Cloudflare UI aren't accessible via process.env or import.meta.env: they are provided to the site as a part of Cloudflare's top-level handler function.

How your framework makes these variables available may differ. In Astro, you can access these variables via context.locals.runtime.env. Other frameworks may provide other options.

However, it's important to note that wrangler.toml should not be used to store secrets. Locally, secrets should be added to a Git ignored .dev.vars file in the main project directory. In production, secrets are added via the Cloudflare UI.

You can also use .dev.vars to override variables set in wrangler.toml when developing locally. Changes made to .dev.vars may require restarting the server locally to resolve the correct value.

10. Pages deployments create publicly accessible "preview deployments" that stick around for awhile

When you push changes to a Pages site, it creates a "preview" URL on a subdomain of pages.dev. Anyone with the URL can view that version of the site, and they are not deleted automatically when a new version of the site is released.

If that makes you nervous, Cloudflare has documentation that lays out how to restrict access to preview deployments through the Cloudflare UI. You can also manually delete previous preview deployments through the UI.

11. Previous deployments of workers are URL accessible

Similar to Pages' "preview deployments," previous worker deployments are URL accessible via a subdomain of workers.dev. Anyone with the URL can view that deployed version of the site.

If that makes you nervous, you can disable them by adding the following top-level configuration option in wrangler.toml:

preview_urls = false

There is no way to delete previous Worker deployments within the Cloudflare UI, but I believe that they are automatically removed after some duration of time (though I'm not 100% sure).

12. Initial deployments are SLOW

After running npx wrangler depoy for the first time, Cloudflare will create a Worker or Page and provide you a preview URL immediately. If you visit that URL right away, you'll see a browser error.

It takes Cloudflare several minutes to set up a new project. Come back to it in a few minutes and you should have a working website.

I hope that you've found this post helpful as you explore hosting your own projects on Cloudflare. It has its quirks, but I've had a good experience so far.

The platform still seems to be evolving rapidly, so please comment to let me know if any of the information in the post has changed and I'll get it updated.

First impressions of Astro: what I liked and disliked

Tyler Smith — Sat, 28 Dec 2024 09:00:22 +0000

I recently started using Astro to rebuild side projects that were originally built with WordPress, Go, Rails, and Hugo. I picked Astro because it had a React-like DX with good language server support, and because it was compatible with serverless hosting platforms that had a generous free tier (Cloudflare, AWS Lambda, etc).

I didn't know much about Astro when I started using it. Now that I've migrated multiple sites, I wanted to share what I liked and disliked about the framework for anyone else considering using it.

Astro: what I liked

At its core, Astro is a static site generator with the ability to produce dynamic server-rendered pages when needed. Astro is a great fit for blogs or small marketing sites with limited interactivity. The framework provides most of the DX from Next.js without the React.js overhead.

Good IntelliSense and code formatting in a server rendered template language

Let's be honest: good language server support and code formatting are severely lacking in traditional server-rendered templating languages. Go templates, Jinja, ERB, and EJS are painfully behind with tooling when compared to their React/Vue/Svelte counterparts. Most server-rendered templating languages have no way of knowing what variables are in scope or what their types are.

With Astro, all of these features are one VS Code extension away.

Inside of Astro templates, you set your data at the top of the template inside of a "code fence" that either runs at build time or when responding to a request on the server. Here's what that looks like in practice:

---
import Layout from "../layouts/Layout.astro";
import { getPosts } from "../data/posts";

const posts: { id, title }[] = await getPosts();
---
<Layout pageTitle="Posts">
  <h1>Posts</h1>

  {post.length > 0 ? (
    <ul>
      {posts.map((post) => (
        <li>
          <a href={`/posts/${post.id}`}>
            {post.title}
          </a>
        </li>
      )}
    </ul>
  ) : null}
</Layout>

Because all of the data for the template is loaded in the "code fence" above the template, the language server can provide auto-completion for the properties of any object defined within the scope. It will also indicate when you are trying to use a variable that doesn't exist.

Astro files can be "components"

One of my biggest gripes with traditional templating languages like Go templates, Jinja, and EJS is that they don't have "components" that can accept children. Most of my websites have a constrained-width "container" UI element of some kind, which ensures that content doesn't fly out to the end of the screen on ultra-wide monitors. If you have a .container class that you manually add to <div /> elements, then this usually works fine. However, if you're using a utility CSS framework like Tailwind then you may find yourself adding the following code to every single page template:

<div
  class="mx-auto px-4 sm:max-w-md md:max-w-lg lg:max-w-xl xl:max-w-2xl"
>
  <!-- Inner-page content goes here... -->
</div>

When you eventually need to change these classes, it's an error-prone pain to update each file manually. But if your templating language doesn't have components that can accept children, it's almost inevitable.

Unlike those traditional templating languages, Astro templates can be used as components that accept children using a <slot /> tag. A long string of utility classes could be extracted into a reusable Astro component:

<div
  class="mx-auto px-4 sm:max-w-md md:max-w-lg lg:max-w-xl xl:max-w-2xl"
>
  <slot />
</div>

The Astro component could then be consumed from another Astro file.

---
import Container from "../components/Container.astro";
---
<Container>
  <h1>Hello, world!</h1>
</Container>

Astro files aren't limited to a single slot: they can have multiple.

My favorite feature of Astro components is that they can accept props within the code fence. Here's an example:

---
type Props = { pageTitle: string; pageDescription: string };

const { pageTitle, pageDescription } = Astro.props;
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>{pageTitle}</title>
    <meta name="description" content={pageDescription} />
  </head>
  <body>
    <slot />
  </body>
</html>

The component can then accept props when used within another file.

---
import Layout from "../layouts/Layout.astro";
---
<Layout
  pageTitle="Tyler's Blog"
  pageDescription="I don't really post on here."
>
  <h1>Tyler's blog</h1>
  <p>Sorry, there's no content yet...</p>
</Layout>

A frontend asset pipeline with live reloads is built-in

I've built my own server-side integrations with Vite before. If you're trying to get something online quickly, this is the kind of commodity feature that you want to avoid building yourself. With Astro, it's built-in.

If you want to add a custom script to an Astro page or component, all you have to do is drop a script tag on the page.

<div>
  <h1>This is my page</h1>
  <script src="../assets/script.ts"></script>
</div>

Astro will automatically compile TS and JS files as a part of a site's build process. You can also write scripts that use imports from node_modules inside of a script tag within an Astro component, and Astro will compile that during build time and extract it to its own file.

<script>
  // This will also compile down to a JavaScript file at build time.

  import axios, { type AxiosRequestConfig, type AxiosResponse } from "axios";

  const response = await axios
    .get<AxiosRequestConfig, AxiosResponse<{foo: string}>>("/some-endpoint");

  console.log(response.data.foo);
</script>

You can include CSS or Scss styles in an Astro file by importing them within the code fence.

---
import "../assets/styles.css";
---

Astro also provides the ability to do scoped styles by using a style tag in an Astro file. This feature may be familiar to Vue users.

Given the following Astro file:

<style>
  .heading {
    color: red;
  }
</style>

<h1 class="heading">
  Hello, world!
</h1>

Astro will render the following:

<style>
  .heading[data-astro-cid-6d7mwtum] {
    color: red;
  }
</style>

<h1 class="heading" data-astro-cid-6d7mwtum>
  Hello, world!
</h1>

The injected data-astro attributes scope the styles to the current component, ensuring that they don't override styles in other components that may use the same class name.

First-class markdown & MDX support

I've lost days trying to figure out the different ways to incorporate markdown and MDX into Next.js. With Astro, it's built-in. Here's what it looks like in practice:

---
import { Content, frontMatter } from "../content/blog-post-1.md";
---

<h1>{frontMatter.title}</h1>

<Content />

Easy, right?

Actions

Actions provide a type-safe way of running backend functions. They provide validation and can handle both JSON and form data. They're easily one of Astro's killer features: all of this would need to be hand-wired in a Next.js app in a bespoke way. They require a little more code than can fit neatly into an example, but they're pretty elegant to use. I'd recommend reading the actions docs page.

No runtime JS cost

There are an endless number of Twitter devs that say React is "fast enough." For a lot of things it's not.

I use Rasbperry Pi 4s for little projects, and you can feel the runtime cost of React. I'm sure it's the same for inexpensive Android phones, except in that case the JS overhead will also drain the battery.

If the only interactivity that my site needs is toggling a nav menu, I'd rather wire that up myself. I'll happily reach for React when I need it, but for so many projects I don't actually need it.

Astro: what I disliked

The things that I dislike about Astro are not unique to the framework: they are ideas borrowed from other tools in the JavaScript ecosystem.

File-based routing

Because Astro employs file-based routing, half of the files in an Astro project end up named index.(astro|js|ts) or [id].(astro|js|ts). File-based routing is an obnoxious pattern that swept the frontend world by storm after Next.js implemented it, and it comes with many drawbacks:

You'll often have 5 tabs open in your editor with the same filename. It will take a minimum of 3 guesses to find the tab you're looking for.
The editor's file fuzzy finder is far less useful because so many files have the same name.
File-based routing scatters one of an application's core concerns across many files and folders, making it difficult to see all routes at a glance within the editor. Instead, you must drill down into several folders to understand what pages are available.

I'll admit: file-based routing feels great when you're making a site with under 10 pages. But as a site grows it adds friction, and you fight the feature more than you benefit from it.

In the JavaScript ecosystem, Remix stands apart by offering a version of file-based routing that flattens all routes into a single directory, and allows a user to opt out of file-based routing entirely with manual route configuration.

File-based routing is my biggest complaint about Astro, but it's a difficult feature to escape. It is implemented in Next.js, Nuxt.js, SvelteKit, and others. What's even stranger is that these frameworks are largely unopinionated about the filenames for other parts of the application. In start contrast to Ruby on Rails, most JavaScript frameworks give you a great degree of freedom in file names and project structure–except for routing. It's a special case, and special cases add complexity to software.

One component per file (kind of)

A JavaScript language feature that I really like is the ability to define multiple variables, functions, and classes in a single file. This makes it easy to colocate related functionality without having to prematurely extract it to other files because of language-level constraints.

Much like Vue's single-file components, Astro files allow defining one component per file. This feels tedious to me, but Astro provides a workaround.

Astro can embed pre-rendered React, Vue, Svelte, Solid, and Preact components directly into its templates without loading any client-side JavaScript. Preact components pair reasonably well with Astro because Preact JSX is much closer to HTML than React JSX. It does become awkward managing both Astro and Preact components in the same project though, and once I begin using Preact components I find myself moving most of the UI out of Astro files and into Preact.

Final thoughts on Astro

If you're an avid user of Next.js, Nuxt, or SvelteKit and you are happy with your framework, you might not get much out of Astro. However, if you want to ship less JavaScript bloat to your users while retaining the DX of something like Next.js, then Astro might be for you.

Astro is geared towards content-driven websites, and provides markdown support out-of-the-box. Because of its focus on content, it is an ideal developer blogging platform to replace a WordPress or Hugo site. However, it's capable of much more than just content sites through features like Actions.

Despite my strong distaste for file-based routing, my biggest concern with adopting Astro is the potential for breaking changes that would force me to rebuild my sites. JavaScript tools are much more aggressive with breaking changes than tools you find in other language ecosystems. Because I'm so new to Astro, I don't know how much changes from one major version to the next. Even with this concern, I plan to move 5-to-6 of my sites from other platforms to Astro so I can take advantage of its top-notch DX and host the sites inexpensively.

Upsert a row in a DB that doesn't use primary keys or unique constraints

Tyler Smith — Sat, 19 Oct 2024 01:50:34 +0000

During my 7-year career as a programmer, I've interacted with SQL via an ORM most of the time. One feature from Laravel's Eloquent ORM that I find particularly useful is its updateOrInsert() method:

DB::table('posts')
    ->updateOrInsert(
        ['slug' => 'about'], // matching condition
        ['content' => 'Like and subscribe'] // created or updated values
    );

In the example above, Eloquent will look for a row in the posts table where the slug equals "about". If a row exists with that slug, Eloquent will update that row's content to "Like and subscribe". If a row doesn't exist with that slug, Eloquent will create a new row with the slug of "about" and the content of "Like and subscribe".

The problem: no primary key or unique constraints

I'm currently writing a migration script to move page data from an old WordPress site to a new WordPress site. The script connects to the database of the old site then creates an SQL file that can be imported into the database of the new site. The new site already has some pages that have been moved manually, but their content may be out-of-date. When a page already exists on the new site, we don't want to create it again: we want to update the page that's already there. We can determine if the page already exists by using the post_name column in the WordPress database, which corresponds to the page's URL slug.

If the post_name were the primary key, we could accomplish something similar to Eloquent's createOrUpdate() method using a REPLACE statement, but the post_name is not the primary key.

If the post_name had a unique constraint, we could accomplish something similar to Eloquent's createOrUpdate() method using an INSERT ... ON DUPLICATE KEY UPDATE statement, but the post_name does not have a unique constraint.

Ah, the joys of WordPress.

I looked into MySQL's IF statement, but the IF statement only works in stored procedures, triggers, and functions. I did not want to create stored procedures in the SQL file that I would import to the new site's database, so I had to search for other options.

The solution: 2 statements

The simplest solution I could find to emulating Eloquent's updateOrInsert()'s functionality in pure SQL was to break the problem into two pieces:

Update any existing rows with a matching slug.
Create a new row if there are no rows with matching slugs.

Here's what that looks like in practice:

-- Update the post if it already exists.

UPDATE wp_posts
SET post_type = 'page',
    post_title = 'About',
    post_content = 'Like and subscribe'
WHERE post_name = 'about';

-- Create a new post if it does not exist.

INSERT INTO wp_posts (post_name, post_type, post_title, post_content)
SELECT 'about', 'page', 'About', 'Like and subscribe'
WHERE NOT EXISTS (
    SELECT 1
    FROM wp_posts
    WHERE post_name = 'about'
);

NOTE: This example omits many of WordPress's required wp_posts columns for brevity and clarity.

Learning about the INSERT ... SELECT statement was the "aha" moment for me. It is intended to use the results of a query from another table to perform many inserts at once. However, you can use-and-abuse SQL's capabilities by providing your own values and only performing the insert when a post with a post_name of "about" does not exist.

Is this the most elegant and efficient solution to this problem? Probably not. But it's good enough for a one-off migration of a WordPress site, and it allows you to update or insert a row without needing stored procedures or any application logic. Hopefully this post helps you as you write powerful queries without the aid of an ORM.

Stop the cursor from jumping to the corner of the screen on a Lenovo Yoga laptop

Tyler Smith — Wed, 16 Oct 2024 00:23:37 +0000

I was using Windows 11 on my Lenovo Yoga today, and suddenly my cursor started jumping to the top left corner of my screen. This was happening every few seconds, and it even happened when I wasn't touching the trackpad or screen.

I did the following troubleshooting steps to try to resolve the issue, all of which were unsuccessful:

I restarted the computer.
I cleaned the sides of the trackpad with a toothpick in case something was stuck.
I adjusted the mouse pointer speed in the mouse settings.
I performed a clean boot.
I updated the drivers and BIOS by using Lenovo System Update several times.
I disabled the trackpad in Windows Settings.
I disabled the touchscreen using Device Manager and plugged in a mouse.
I disabled every mouse listed in Device Manager.
I attempted to update the drivers for the mouse, touchscreen, and trackpad.
I turned off Bluetooth incase a wireless mouse was somehow connected.
I hit my computer hard many times.
I created a Pop!_OS bootable USB and booted into it to ensure that it wasn't a Windows setting that was causing this.

Even when I booted into Linux, I was still experiencing my cursor jumping around the screen to the top left corner. Curiously however, the cursor didn't jump around when I was in the system BIOS. This meant that it probably wasn't strictly a hardware issue.

The culprit

The culprit was not the touchpad, touchscreen, or mouse: it was the "Pen."

I found this curious because my Lenovo Yoga did not come with a Pen, nor have I ever used one with this laptop. But disabling the pen fixes the issue.

Disabling the pen on Windows

To disable the pen on Windows, open the start menu, type "Device Manager," then select Device Manager to open it. Inside Device Manager, open Human Interface Devices, right-click HID-compliant pen, then select Disable device.

It may take a few attempts to do this successfully while the cursor is jumping around, but once you disable the pen it should stop the cursor jumping immediately. If you disable the pen and the cursor is still jumping around, then you unfortunately have a different problem.

Disabling the pen on Linux

To disable the pen on Linux, you'll need a package called xinput. I'll let you look up the instructions for installing that on your respective distro.

Once you've ensured that xinput is installed, run the following command to list the devices:

xinput list

xinput should display a list like the one below:

⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SYNACFFE:00 06CB:CEFE Mouse               id=9    [slave  pointer  (2)]
⎜   ↳ SYNACFFE:00 06CB:CEFE Touchpad            id=10   [slave  pointer  (2)]
⎜   ↳ Wacom HID 5362 Pen stylus                 id=11   [slave  pointer  (2)]
⎜   ↳ Wacom HID 5362 Pen eraser                 id=16   [slave  pointer  (2)]
⎜   ↳ Wacom HID 5362 Finger touch               id=12   [slave  pointer  (2)]
⎜   ↳ Logitech USB Optical Mouse                id=8    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Video Bus                                   id=6    [slave  keyboard (3)]
    ↳ Power Button                                id=7    [slave  keyboard (3)]
    ↳ Ideapad extra buttons                       id=13   [slave  keyboard (3)]
    ↳ sof-hda-dsp Headphone                       id=14   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard                id=15   [slave  keyboard (3)]

Look for the entry named Wacom HID 5362 Pen stylus and grab its ID. You can disable the device by it's ID with the following command:

# "11" is the device ID for the pen that we found in the step above.

xinput disable 11

You can run xinput list again to confirm that the pen device has been disabled:

xinput list

⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SYNACFFE:00 06CB:CEFE Mouse               id=9    [slave  pointer  (2)]
⎜   ↳ SYNACFFE:00 06CB:CEFE Touchpad            id=10   [slave  pointer  (2)]
⎜   ↳ Wacom HID 5362 Pen eraser                 id=16   [slave  pointer  (2)]
⎜   ↳ Logitech USB Optical Mouse                id=8    [slave  pointer  (2)]
⎜   ↳ Wacom HID 5362 Finger touch               id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Video Bus                                   id=6    [slave  keyboard (3)]
    ↳ Power Button                                id=7    [slave  keyboard (3)]
    ↳ Ideapad extra buttons                       id=13   [slave  keyboard (3)]
    ↳ sof-hda-dsp Headphone                       id=14   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard                id=15   [slave  keyboard (3)]
∼ Wacom HID 5362 Pen stylus

Once you disable the pen, it should stop the cursor jumping immediately. If you disable the pen and the cursor is still jumping around, then you unfortunately have a different problem.

I hope you found this helpful. I'm frustrated that I'm experiencing this issue: in the year and a half I've owned this machine I've probably only used it less than 100 hours. If I had purchased the machine for digital art I'd be furious. Thankfully I'm terrible at art, so I can continue using this machine without missing the pen functionality.

The winner of WordPress vs WP Engine will be Microsoft

Tyler Smith — Tue, 15 Oct 2024 10:14:53 +0000

Automattic, the commercial company that guides WordPress, has launched a scorched-Earth campaign against WP Engine. For those who don't know, WP Engine is a popular hosting provider for WordPress websites. It also owns many of the plugins that elevate WordPress from a simple blogging platform to an enterprise-capable content management system.

Less than a month ago, Automattic CEO Matt Muellenweg delivered a keynote at WordCamp US that condemned WP Engine for its lack of contributions to WordPress core. Mullenweg went on to make the argument that private equity firms like the one that owns WP Engine hollow out and destroy open source communities.

An abbreviated timeline

The weeks that have followed the WordCamp keynote have felt like months. In that time, the following events have unfolded:

September 23: WP Engine sent a cease and desist letter to Automattic. The letter includes screenshots of texts from Mullenweg threatening to take a "scorched earth nuclear approach" with WP Engine if they did not agree to pay a percentage of their gross revenue to Automattic for a WordPress trademark license (this is now known to be 8%). WP Engine has existed since 2010 and has never previously needed a license.

September 24: While the WordPress Foundation's trademark policy had permitted the free use of "WP" as recently as mid-September, the policy was updated to call out WP Engine's usage of "WP" because it "confuses people."

September 25: In retaliation for the cease and desist letter, WordPress.org blocked WP Engine's customers from receiving theme and plugin updates, leaving millions of sites potentially vulnerable to security issues.

September 26: In an interview with ThePrimeagen, Mullenweg says that Automattic is using trademark law against WP Engine because there's no law that says that WP Engine has to contribute back. He elaborated on this point in an interview with Theo.

October 2: WP Engine sued Automattic. The lawsuit alleged Mullenweg attempted extortion against WP Engine's CEO.

October 5: Automattic tweets that they have "responsibly disclosed" a security vulnerability in Advanced Custom Fields to WP Engine. However, WP Engine was blocked from uploading their plugins to WordPress.org. Further, announcing a discovered vulnerability before it is fixed is out of line with Automattic's security policy and WordPress's security policy. It also goes against the spirit of responsible disclosure. The tweet has since been deleted, but screenshots can be found on Twitter and the tweet's data was captured by the Wayback Machine.

October 12: Automattic takes control of the Advanced Custom Fields plugin listing, rebranding it as Secure Custom Fields. This was done vaguely under the guise of security-related concerns. ACF had already patched the vulnerability, but WordPress.org had locked them out of publishing the updates. The transition from ACF to SCF would happen automatically, potentially without users understanding that the plugin is not from the original author. If viewed through the right lens, this could be seen as a supply chain attack. Meanwhile, the rebranded plugin broke sites in the wild.

The preceding timeline excludes the WordPress Twitter bullying community members, Mullenweg's now-deleted tirade against DHH, or the checkbox ordeal. You can find those and more on What in the WorldPress?, bullenweg.com and mullenweg.wtf.

WordPress impact

What will the result of this feud between WordPress and WP Engine be? It will be the total vindication of the open source alarmists in the late 90s and early 2000s. Steve Ballmer is smiling right now, believing that he was right to call Linux and the GPL a cancer.

In the short term, both WordPress and WP Engine will probably take small hits in adoption as a result of this "scorched earth nuclear" conflict. But there currently aren't great alternatives to WordPress or WP Engine: for better or worse, both are best-in-class for the moment. And migrating existing sites off of WordPress or WP Engine won't pencil out for many companies in the short-term, even though there is an ecosystem of alternative content management systems and hosting providers.

However, migrating sooner rather than later might make sense for some sites. WhiteHouse.gov is a WordPress site, and WordPress.org's capricious security policies could cause a vulnerability that allows a bad actor to post on the site that the US has declared war on China and is dropping bombs within the hour. What happens next? Is WordPress really so good that it's worth that risk?

Changing tides in OSS

The security risks that came with open source software were generally worth it to companies because of the associated cost savings. Open sourced licensed software was often "free as in beer," or it at least had predictable pricing. The WordPress conflict upends that predictability: there is now a prominent case study of a major open source maintainer allegedly attempting to extort a CEO for money once their company got big. CEOs don't love unpredictable cost structures, and they really don't love being extorted.

Let's take a step back and look at the open source ecosystem outside of content management systems. It's not a stretch to think that there are thousands of risk-averse CTOs watching the utter chaos of the WordPress conflict unfold and seriously reconsidering using Node/Rust/Elixir/etc for their next greenfield projects. Some of these folks were around when companies first started adopting open source software like Linux, Apache, MySQL, and PHP in their stacks. There was incredible skepticism that free software could compete with companies that sold developer tools as their core business. On top of that, the backdrop for this WordPress conflict is years of OSS license rug pulls from Redis, Terraform, Elasticsearch, and others.

Microsoft will win, open source will lose

There's an old tech phrase: "No one ever got fired for buying IBM."

IBM may not have always been the best option and it certainly wasn't the cheapest, but it was a safe bet. If you're an enterprise CTO looking for the programming equivalent of that safe bet, what do you buy? Microsoft.

The result of this WordPress debacle will almost certainly be a gentle migration away from exciting open source technologies back towards tried-and-true corporate frameworks like Microsoft ASP.NET. Those apps will run on Microsoft IIS servers, sparing us the cancer of open source software like Linux. Matt Mullenweg has probably done more for Adobe Experience Manager in the past month than their marketing team has done in the past year. Mullenweg has given Oracle sales reps one more talking point about why their clients should stay locked into their safe contracts. In this holy war for open source, we've seen how fragile open source is. Proprietary tech companies will use their lack of BDFL as a selling point.

The more that WordPress "wins" against WP Engine, the more that open source will lose trust of the people who depend on it. I hope you like writing C# and deploying on Azure.

For the sake of a future where open source is still a viable option, this conflict must end quickly, and WP Engine must win. An enormous amount of damage has already been done, but shaking down users of your free software because they became successful is a precedent than open source software might not survive in the current tech landscape.

Mock functions in individual tests using Jest

Tyler Smith — Sun, 04 Aug 2024 01:31:46 +0000

Sometimes you want to mock a function in some tests but not others. Sometimes you want to supply different mocks to different tests. Jest makes this tricky: its default behavior is to override a package's function for a whole test file, not just a single test. This seems odd if you've used flexible tools like Python's @patch or Laravel's service container.

This post will show you how to mock functions for individual tests, then fallback to the original implementation if no mock was provided. Examples will be given for both CommonJS and ES modules. The techniques demonstrated in this post will work for both first-party modules and third-party packages.

CommonJS vs ES Modules

Since we'll be covering multiple module systems in this post, it's important to understand what they are.

CommonJS (abbreviated CJS) is the module system in Node.js. It exports functions using module.exports and imports functions using require():

// CommonJS export 

function greet() {
  return "Hello, world!";
}

module.exports = { greet };

// CommonJS import

const getUsersList = require('./greet');

ES modules (abbreviated ESM) is the module system that's used by the browser. It exports functions using the export keyword and imports functions using the import keyword:

// ES module export

export default function greet() {
  return "Hello, world!";
}

// ES module import

import { greet } from "./greet";

Most frontend JavaScript developers use ES modules at the time of writing this post, and many server-side JS devs use them as well. However, CommonJS is still the default for Node. Regardless of which system you use, it is worth reading the whole article to learn about Jest's mocking system.

Mocking a single exported function with CommonJS

Typically a CommonJS file will export their modules using object syntax, like shown below:

// CommonJS export 

function greet() {
  return "Hello, world!";
}

module.exports = { greet: greet };

However, it is also possible to export a function by itself:

// CommonJS export 

function greet() {
  return "Hello, world!";
}

module.exports = greet;

I wouldn't necessarily recommend doing this in your own code: exporting an object will give you fewer headaches while developing your application. However, it is common enough that it's worth discussing how to mock a bare exported function in CommonJS, then fallback to the original if a test does not provide its own implementation.

Let's say we have the following CommonJS file we'd like to mock during tests:

// cjsFunction.js

function testFunc() {
  return "original";
}

module.exports = testFunc;

We could mock it in our tests using the following code:

const testFunc = require("./cjsFunction");

jest.mock("./cjsFunction");

beforeEach(() => {
  testFunc.mockImplementation(jest.requireActual("./cjsFunction"));
});

it("can override the implementation for a single test", () => {
  testFunc.mockImplementation(() => "mock implementation");

  expect(testFunc()).toBe("mock implementation");
  expect(testFunc.mock.calls).toHaveLength(1);
});

it("can override the return value for a single test", () => {
  testFunc.mockReturnValue("mock return value");

  expect(testFunc()).toBe("mock return value");
  expect(testFunc.mock.calls).toHaveLength(1);
});

it("returns the original implementation when no overrides exist", () => {
  expect(testFunc()).toBe("original");
  expect(testFunc.mock.calls).toHaveLength(1);
});

How it works

When we call jest.mock("./cjsFunction"), this replaces the module (the file and all of its exports) with an auto-mock (docs). When an auto-mock is called, it will return undefined. However, it will provide methods for overriding the mock's implementation, return value, and more. You can see all the properties and methods it provides in the Jest Mock Functions documentation.

We can use the mock's mockImplementation() method to automatically set the mock's implementation to the original module's implementation. Jest provides a jest.requireActual() method that will always load the original module, even if it is currently being mocked.

Mock implementations and return values are automatically cleared after each test, so we can pass a callback function to Jest's beforeEach() function that sets the implementation of the mock to the original implementation before each test. Then any tests that wish to provide their own return value or implementation can do that manually within the test body.

Mocking CommonJS when exporting an object

Let's say that the code above had exported an object instead of a single function:

// cjsModule.js

function testFunc() {
  return "original";
}

module.exports = {
  testFunc: testFunc,
};

Our tests would then look like this:

const cjsModule = require("./cjsModule");

afterEach(() => {
  jest.restoreAllMocks();
});

it("can override the implementation for a single test", () => {
  jest
    .spyOn(cjsModule, "testFunc")
    .mockImplementation(() => "mock implementation");

  expect(cjsModule.testFunc()).toBe("mock implementation");
  expect(cjsModule.testFunc.mock.calls).toHaveLength(1);
});

it("can override the return value for a single test", () => {
  jest.spyOn(cjsModule, "testFunc").mockReturnValue("mock return value");

  expect(cjsModule.testFunc()).toBe("mock return value");
  expect(cjsModule.testFunc.mock.calls).toHaveLength(1);
});

it("returns the original implementation when no overrides exist", () => {
  expect(cjsModule.testFunc()).toBe("original");
});

it("can spy on calls while keeping the original implementation", () => {
  jest.spyOn(cjsModule, "testFunc");

  expect(cjsModule.testFunc()).toBe("original");
  expect(cjsModule.testFunc.mock.calls).toHaveLength(1);
});

How it works

The jest.spyOn() method allows Jest to record calls to a method on an object and provide its own replacement. This only works on objects, and we can use it because our module is exporting an object that contains our function.

The spyOn() method is a mock, so its state must be reset. The Jest spyOn() documentation recommends resetting the state using jest.restoreAllMocks() in an afterEach() callback, which is what we did above. If we did not do this, the mock would return undefined in the next test after spyOn() was called.

Mocking ES modules

ES modules can have default and named exports:

// esmModule.js

export default function () {
  return "original default";
}

export function named() {
  return "original named";
}

Here's what the tests for the file above would look like:

import * as esmModule from "./esmModule";

afterEach(() => {
  jest.restoreAllMocks();
});

it("can override the implementation for a single test", () => {
  jest
    .spyOn(esmModule, "default")
    .mockImplementation(() => "mock implementation default");
  jest
    .spyOn(esmModule, "named")
    .mockImplementation(() => "mock implementation named");

  expect(esmModule.default()).toBe("mock implementation default");
  expect(esmModule.named()).toBe("mock implementation named");

  expect(esmModule.default.mock.calls).toHaveLength(1);
  expect(esmModule.named.mock.calls).toHaveLength(1);
});

it("can override the return value for a single test", () => {
  jest.spyOn(esmModule, "default").mockReturnValue("mock return value default");
  jest.spyOn(esmModule, "named").mockReturnValue("mock return value named");

  expect(esmModule.default()).toBe("mock return value default");
  expect(esmModule.named()).toBe("mock return value named");

  expect(esmModule.default.mock.calls).toHaveLength(1);
  expect(esmModule.named.mock.calls).toHaveLength(1);
});

it("returns the original implementation when no overrides exist", () => {
  expect(esmModule.default()).toBe("original default");
  expect(esmModule.named()).toBe("original named");
});

How it works

This looks almost the same as the previous CommonJS example, with a couple of key differences.

First, we're importing our module as a namespace import.

import * as esmModule from "./esmModule";

Then when we want to spy on the default export, we use "default":

  jest
    .spyOn(esmModule, "default")
    .mockImplementation(() => "mock implementation default");

Troubleshooting ES module imports

Sometimes when trying to call jest.spyOn() with a third-party package, you'll get an error like the one below:

    TypeError: Cannot redefine property: useNavigate
        at Function.defineProperty (<anonymous>)

When you run into this error, you'll need to mock the package that is causing the issue:

import * as reactRouterDOM from "react-router-dom";

// ADD THIS:
jest.mock("react-router-dom", () => {
  const originalModule = jest.requireActual("react-router-dom");

  return {
    __esModule: true,
    ...originalModule,
  };
});

afterEach(() => {
  jest.restoreAllMocks();
});

This code replaces the module with a Jest ES Module mock that contains all of the module's original properties using jest.mocks's factory parameter. The __esModule property is required whenever using a factory parameter in jest.mock to mock an ES module (docs).

If you wanted, you could also replace an individual function in the factory parameter. For example, React Router will throw an error if a consumer calls useNavigate() outside of a Router context, so we could use jest.mock() to replace that function throughout the whole test file if we desired:

jest.mock("react-router-dom", () => {
  const originalModule = jest.requireActual("react-router-dom");

  return {
    __esModule: true,
    ...originalModule,

    // Dummy that does nothing.
    useNavigate() {
      return function navigate(_location) {
        return;
      };
    },
  };
});

Wrapping up

I hope this information is valuable as you write your own tests. Not every app will benefit from being able to fallback to the default implementation when no implementation is provided in a test itself. Indeed, many apps will want to use the same mock for a whole testing file. However, the techniques shown in this post will give you fine-grained control over your mocking, allowing you to mock a function for a single test in Jest.

Let me know if I missed something or if there's something that I didn't include in this post that should be here.

Get better autocomplete for Faker when using factory_boy

Tyler Smith — Sat, 27 Jul 2024 05:03:24 +0000

Before language server powered autocomplete was ubiquitous, it didn't matter if code was written in a way that made autocomplete easy. Popular text editors like Sublime weren't able to understand code enough to provide meaningful suggestions. Programmers either memorized the commands of their dependencies or they referenced the documentation.

In 2024 autocomplete is everywhere, but our packages haven't necessarily made its job easy. Take this example from Factory Boy's documentation:

import factory
from datetime import datetime
from .models import User

class UserFactory(factory.Factory):
    class Meta:
        model = User

    arrival = factory.Faker(
        'date_between_dates',
        date_start=datetime.date(2020, 1, 1),
        date_end=datetime.date(2020, 5, 31),
    )

The arrival attribute calls Faker's date_between_dates() method. Unfortunately, factory.Faker() does not tell you what Faker methods are available, and it won't tell you what parameters a Faker method accepts once you select one. This code mitigates the benefits that language servers provide.

Autocompleting Faker in factories

You can get autocomplete while using Faker with factory_boy by wrapping a Faker call in factory.LazyFunction():

import factory
from datetime import datetime
from .models import User

fake = Faker()

class UserFactory(factory.Factory):
    class Meta:
        model = User

    arrival = factory.LazyFunction(lambda: fake.date_between_dates(
        date_start=datetime.date(2020, 1, 1),
        date_end=datetime.date(2020, 5, 31),
    ))

Functions passed to factory.LazyFunction() evaluate when the factory creates an instance. We wrap our faker call in a lambda so we can provide it arguments. And your language server can show you what parameters fake.date_between_dates() accepts.

There's less set-up when the faker function doesn't need any arguments. Here is how you could use factory.LazyFunction() with Faker's first_name() and last_name() methods:

import factory
from datetime import datetime
from .models import User

fake = Faker()

class UserFactory(factory.Factory):
    class Meta:
        model = User

    first_name = factory.LazyFunction(fake.first_name)
    last_name = factory.LazyFunction(fake.last_name)

The biggest advantage of using factory.LazyFunction() is that it doesn't just work for Faker: you can use it to get factory_boy to call any function. The resulting code is a little longer than it would be if we had used factory.Faker(), but the assistance from the language server is worth it to me. Without it, I might need to constantly check documentation.

If it's too much to type, you can alias it to something shorter such as LazyFn:

from factory import Factory, LazyFunction as LazyFn
from datetime import datetime
from .models import User

fake = Faker()

class UserFactory(Factory):
    class Meta:
        model = User

    first_name = LazyFn(fake.first_name)
    last_name = LazyFn(fake.last_name)

DEV Community: Tyler Smith

Alma and Rocky Linux ISOs: DVD vs Boot vs Minimal

DVD ISO

Boot ISO

Minimal ISO

Which ISO should you download?

OpenStreetMap's software ecosystem and tools

openstreetmap.org

OpenStreetMap data

Rendering an OpenStreetMap on the web

Map libraries

Raster tiles

Vector tiles

Static maps

Geocoding

Routing

OpenStreetMap's license

Attribution requirements

Where to start

Absolute paths for assets in iOS & Android Cordova apps

Using scheme and hostname within config.xml

Compatibility

Did Cordova always work like this?

Using the file path

Other resources

How to hold apps for manual release on Google Play Console and Apple's App Store Connect

Google Play Console (Android)

App Store Connect (iOS)

Implementing & testing Socialite authentication in Laravel

What does Laravel Socialite do and not do?

Prerequisites: creating a Google Cloud project

Setting up a minimal Laravel project with Socialite

Testing Socialite with Pest

How the tests work

Wrapping up

12 things I learned about hosting serverless sites on Cloudflare

1. Cloudflare has two competing offerings for building serverless websites: Workers and Pages

2. If you want to put your Pages or Workers site on an apex domain, Cloudflare must manage its DNS

3. If you know that you're going to deploy a site to Cloudflare, it's worth using Cloudflare's tools to create it

4. When you scaffold a site using npm cloudflare create, you can run local versions of Cloudflare services

5. To use a Cloudflare service locally, that service must have an ID in wrangler.toml

6. Compatibility with Node.js isn't 100%

7. Cloudflare Pages do not allow you to set production environment variables in the Cloudflare UI

8. Worker environment variables set in Cloudflare's UI will be overwritten by variables in wrangler.toml

9. Environment variables aren't actually environment variables

10. Pages deployments create publicly accessible "preview deployments" that stick around for awhile

11. Previous deployments of workers are URL accessible

12. Initial deployments are SLOW

First impressions of Astro: what I liked and disliked

Astro: what I liked

Good IntelliSense and code formatting in a server rendered template language

Astro files can be "components"

A frontend asset pipeline with live reloads is built-in

First-class markdown & MDX support

Actions

No runtime JS cost

Astro: what I disliked

File-based routing

One component per file (kind of)

Final thoughts on Astro

Upsert a row in a DB that doesn't use primary keys or unique constraints

The problem: no primary key or unique constraints

The solution: 2 statements

Stop the cursor from jumping to the corner of the screen on a Lenovo Yoga laptop

The culprit

Disabling the pen on Windows

Disabling the pen on Linux

The winner of WordPress vs WP Engine will be Microsoft

An abbreviated timeline

WordPress impact

Changing tides in OSS

Microsoft will win, open source will lose

Mock functions in individual tests using Jest

CommonJS vs ES Modules

Mocking a single exported function with CommonJS

How it works

Mocking CommonJS when exporting an object

How it works

Mocking ES modules

How it works

Using `scheme` and `hostname` within `config.xml`

4. When you scaffold a site using `npm cloudflare create`, you can run local versions of Cloudflare services

5. To use a Cloudflare service locally, that service must have an ID in `wrangler.toml`

8. Worker environment variables set in Cloudflare's UI will be overwritten by variables in `wrangler.toml`