DEV Community: Tommaso Meli

Prisma Generator NestJS DTO — pluggable DTOs with annotations and custom generators

Tommaso Meli — Sat, 23 May 2026 18:41:08 +0000

If you build NestJS APIs on top of Prisma, you've probably felt the friction: your schema is the source of truth, but your DTOs, validation rules, and Swagger metadata live somewhere else — and they drift.

Most Prisma DTO generators solve the basics (Create / Update / Entity classes with decorators). That's useful, but the moment you need custom output — audit metadata, GraphQL types, RBAC manifests, your own validators — you're back to hand-written glue code.

@tommasomeli/prisma-generator-nestjs-dto is a Prisma generator built for that second phase. It emits the usual NestJS DTOs, then gets out of your way — with a plugin API, annotation-driven decorators, and a type-safe config file when the Prisma schema block isn't enough.

What you get out of the box

For every Prisma model User, run npx prisma generate and you get:

src/generated/nestjs-dto/
  user/
    user.entity.ts
    create-user.dto.ts
    update-user.dto.ts
    index.ts
  index.ts

Each file ships with:

class-validator decorators (@IsString, @IsOptional, …)
@nestjs/swagger metadata (@ApiProperty, @ApiHideProperty, …)
Self-contained imports — relation DTOs, @DtoOverrideType targets, and annotation arguments are resolved automatically

Configure it directly in schema.prisma:

generator nestjsDto {
  provider           = "prisma-generator-nestjs-dto"
  output             = "../src/generated/nestjs-dto"
  outputType         = "class"
  outputStructure    = "nestjs"
  fileNamingStrategy = "kebab"
  reExport           = "true"
  classValidator     = "true"
  swaggerDocs        = "true"
  prettier           = "true"
}

Install:

npm i -D @tommasomeli/prisma-generator-nestjs-dto

Annotations — control visibility without touching generated code

Triple-slash comments (///) above models and fields drive the built-in generators. No post-processing, no manual edits.

model User {
  id           Int    @id @default(autoincrement())
  email        String @unique
  name         String
  /// @DtoHidden
  passwordHash String
  /// @DtoReadOnly
  createdAt    DateTime @default(now())
}

Annotation	Effect
`@DtoHidden`	Hide everywhere
`@DtoReadOnly`	Exclude from Create and Update DTOs
`@DtoEntityHidden`	Hide in the Entity (API response)
`@DtoCreateHidden` / `@DtoUpdateHidden`	Hide in one DTO only
`@DtoOverrideType(MyType)`	Override the TypeScript type (auto-imported)
`@DtoIgnoreModel`	Skip the model entirely

You can also bind your own validators and decorators via config — more on that below.

The plugin system — when built-in DTOs aren't enough

The differentiator is extraGenerators: drop in any class extending BaseGenerator and it runs alongside the built-ins in the same pipeline.

A plugin receives:

The parsed model graph (with annotations on every field)
Resolved config (extraDecorators, extraValidators, extraImports, …)
Import-merging helpers (addImport, formatImports, getTemplate)

Here's a minimal plugin that reuses the built-in renderer to emit an Entity without class-validator:

import { isEntityHidden } from '@tommasomeli/prisma-generator-nestjs-dto';
import { BaseGenerator } from '@tommasomeli/prisma-generator-nestjs-dto';
import type { Field, File, Model } from '@tommasomeli/prisma-generator-nestjs-dto';

export default class EntityDtoGenerator extends BaseGenerator {
  filePrefix = '';
  fileSuffix = '.entity';
  classPrefix = '';
  classSuffix = '';

  async generate(): Promise<File[]> {
    return this.models.map((model) => {
      const filteredFields = model.fields.filter((f: Field) => !isEntityHidden(f));
      const processedModel: Model = { ...model, fields: filteredFields as Field[] };
      const outputPath = this.getPath(model);
      return {
        path: outputPath,
        content: this.getTemplate({ model: processedModel, classValidator: false, outputPath }),
      };
    });
  }
}

Lifecycle hooks

Plugins can hook the full run:

beforeAll(models) — mutate the shared model list before any generator runs (shared pre-pass)
afterAll(files) — append barrels, audit reports, or aggregated indexes after all generators finish

TypeScript plugins, no precompilation

Point extraGenerators at a .ts file and the generator loads it via jiti. No build step required for your plugin.

Real example: custom `@Auditable` annotation

The repo includes a runnable example under examples/blog/.

Schema — annotate models with a custom @Auditable name:

/// @Auditable("user_audit")
model User {
  id           Int      @id @default(autoincrement())
  email        String   @unique
  /// @DtoHidden
  passwordHash String
  posts        Post[]
}

/// @Auditable("post_audit")
model Post {
  id       Int    @id @default(autoincrement())
  title    String
  author   User   @relation(fields: [authorId], references: [id])
  authorId Int
}

Config — register the annotation and the plugin:

import { from, type GeneratorConfigFile } from '@tommasomeli/prisma-generator-nestjs-dto';

export default {
  extraAnnotations: ['Auditable'],
  extraGenerators: from('./generators/audit-generator.ts', ['AuditGenerator']),
} satisfies GeneratorConfigFile;

Output — alongside the usual DTOs, you get per-model audit metadata and an aggregated index:

generated/
  user/user.audit.ts
  post/post.audit.ts
  audit-index.ts    ← emitted by AuditGenerator#afterAll

Type-safe external config

Prisma's generator block is great for simple flags, but it can't express nested objects or multi-line arrays. For anything richer, use a configFile:

generator nestjsDto {
  provider   = "prisma-generator-nestjs-dto"
  output     = "../generated"
  configFile = "../nestjs-dto.config.ts"
}

The from() helper validates paths and named exports at compile time (the import closure is never invoked at runtime):

import { from, fromNamespace, type GeneratorConfigFile } from '@tommasomeli/prisma-generator-nestjs-dto';

export default {
  extraValidators: from(() => import('src/common/validators'), ['IsUnique', 'IsStrongPassword']),
  extraDecorators: from(() => import('src/common/decorators'), ['Trim', 'Sanitize']),
  extraScalars: {
    Decimal: { ts: 'Decimal', from: 'decimal.js' },
    Json:    { ts: 'MyJson', from: 'src/json', apiType: 'Object' },
  },
} satisfies GeneratorConfigFile;

Then wire annotations in the schema:

model User {
  /// @IsUnique()
  email    String @unique
  /// @IsStrongPassword({ minLength: 10 })
  password String
  /// @Trim()
  name     String
}

If a custom validator collides by name with a built-in (IsBoolean, ApiProperty, …), your module wins for that symbol only.

Optional runtime manifest

Enable emitManifest = "true" to get:

manifest.ts — Record<Prisma.ModelName, { primaryKey, entityFields, relations }> for select builders, audit middleware, RBAC field lists
model-entity-map.ts — type-only map from model names to Entity classes

Useful when you need schema-aware runtime logic without parsing Prisma DMMF yourself.

How it compares

	This generator	Typical Prisma NestJS DTO generators
Create / Update / Entity DTOs	✅	✅
Swagger + class-validator	✅	✅
Annotation-driven hide / readonly / type override	✅	partial
Pluggable sub-generators	✅	❌
Custom annotations for plugins	✅	❌
Override built-in imports by name	✅	❌
Type-safe external `configFile`	✅	❌
Optional runtime manifest	✅	❌

Try it

npm i -D @tommasomeli/prisma-generator-nestjs-dto
npx prisma generate

GitHub: github.com/tommasomeli/prisma-generator-nestjs-dto
npm: @tommasomeli/prisma-generator-nestjs-dto
Example: examples/blog/

Issues and PRs are welcome — MIT licensed.

If this saves you time on your NestJS + Prisma stack, a ⭐ on the repo (or a coffee ☕) goes a long way.

WordPress plugin boilerplate with React & Vite

Tommaso Meli — Sat, 23 May 2026 18:03:56 +0000

Building a WordPress plugin in 2026 still means stitching together half a dozen concerns before you write your first feature: PHP bootstrap, REST routes, asset pipelines, admin UI, i18n, release ZIPs, and (if you're lucky) some kind of dev proxy so you're not manually refreshing minified bundles.

I've done this enough times for client projects that I finally productized the scaffolding. It's called Vipresso — a GPL boilerplate you fork once, rename once, and ship from.

Try it in the browser (no install):

WordPress Playground demo

Repo: https://github.com/tommasomeli/vipresso

The problem I kept hitting

Most "WordPress + React" starters solve one layer well and leave you maintaining registration lists forever:

You add a REST handler → edit a central routes file
You add an admin tab → wire React Router manually
You add a shortcode → hope visitors don't download your entire admin bundle
You cut a release → hand-build a ZIP and pray the headers are correct

WordPress already has great primitives (capabilities, options, REST, hooks, cron, WP-CLI). What was missing, for me, was DX that respects those primitives while feeling like a normal Vite + TypeScript app.

What Vipresso actually is

Not a plugin you install on a site. A boilerplate repo you fork into your own product:

React 19 + Vite + TypeScript admin SPA with HMR
Real WordPress in Docker — Vite proxies everything except your bundle
Auto-discovery on both sides — drop a file, no manual registration
Dual bundles — app.js (admin) vs viewer.js (public shortcodes only)
Plop generators — routes, REST handlers, widgets, metaboxes, cron, WP-CLI
Schema-driven settings — JSON schema → PHP store + React UI
GitHub Actions — lint, Vitest, PHP syntax, Docker + Playwright smoke
Release ZIP + in-plugin auto-updates from GitHub Releases

Fork → npm run plugin:rename -- YourPlugin → build features → npm run build:zip.

Architecture: two discovery systems, one repo

├── widgets/          # PHP + TSX + manifest.json
├── shortcodes/       # public-facing, viewer bundle only
├── metaboxes/
├── shared/           # settings.json + generated routes.json
├── src/              # React app (main.tsx + viewer.tsx)
└── plugin/           # WordPress plugin root (Bootstrap, Routes, Assets…)

Frontend: Vite import.meta.glob picks up pages, widgets, shortcodes.

Backend: Bootstrap.php scans for RouteProvider classes, cron jobs, WP-CLI commands.

In dev, feature folders are bind-mounted inside plugin/ so PHP and Node see identical paths. The release script copies them in before zipping.

REST without a registration file

Drop a class, implement RouteProvider, done:

final class BillingHandler implements \Vipresso\RouteProvider
{
    public static function routes(): array {
        return [
            ['/billing', \WP_REST_Server::READABLE, [self::class, 'list']],
            ['/billing', \WP_REST_Server::CREATABLE, [self::class, 'create'], null, [
                'amount'   => ['type' => 'number', 'required' => true],
                'currency' => ['type' => 'string', 'enum' => ['EUR', 'USD']],
            ]],
        ];
    }
}

From React: api.get<T>("/billing") — typed client, namespace from .env.

Keep handlers thin; push business logic into Actions/Services. WordPress coding conventions still apply.

Dual bundles matter

src/main.tsx → admin SPA, dashboard widgets, metaboxes.

src/viewer.tsx → shortcodes only.

Public visitors never download admin code. Obvious in hindsight, rarely default in starter templates.

Dev workflow

cp .env.example .env
pnpm install
docker compose up -d
pnpm run setup    # WP install + plugin activation via wp-cli
pnpm run dev      # Vite HMR on :3333, proxies WP on :8888

One .env drives PHP constants, Vite imports, Docker ports, and plugin.php / readme.txt headers (regenerated on every dev/build).

Live demo without a server

The Playground blueprint boots throwaway WordPress with the plugin pre-installed and admin auto-login — PHP-WASM in the browser, nothing on your infra:

npm run gen:playground   # writes wp-playground-blueprint.json

Publish the blueprint JSON + release ZIP anywhere public; link from your README.

Who is this for?

Agency devs shipping custom admin tools on WordPress
Indie hackers who want WP's ecosystem (users, roles, posts, plugins) with modern frontend DX
Teams tired of re-scaffolding the same release/REST/i18n plumbing

Not for: "I want a SaaS with auth and billing" — this is WordPress-native.

What's next

I'm using Vipresso as the base for client plugins and iterating in public. If you fork it, I'd love to hear what broke or what's missing.

Issues / feature requests: GitHub
Questions / ideas: GitHub Discussions

If this saves you a week of scaffolding, a ⭐ on the repo helps more than you'd think.

GPL v2+. Same license as WordPress. Fork it, rename it, ship it.

Free sshfs GUI for macOS — mount remote folders in Finder

Tommaso Meli — Sat, 23 May 2026 17:17:17 +0000

If you manage Linux servers from a Mac, you've probably been here:

sshfs user@host:/var/www ~/mnt/prod -o reconnect,auto_cache,noappledouble

It works. Until you have four servers, a laptop that sleeps, and a LaunchAgent you copied from a gist two years ago.

I wanted real sshfs mounts in Finder — not another SFTP client, not SMB on the VPS — with saved configs and one-click mount/unmount. So I built SSHFS GUI: free, open source, signed macOS DMG.

The problem with sshfs on macOS

Linux makes this easy. On Mac, it's a stack:

A FUSE implementation (FUSE-T or macFUSE)
An sshfs binary (Homebrew core sshfs is Linux-only — you need fuse-t-sshfs or gromgit/fuse/sshfs-mac)
Your mount command, local mount point, reconnect flags, auth

Finder can't mount SSH natively. Tools like Cyberduck are excellent for transfers, but a different workflow than "this remote path is a volume."

I kept rewriting the same commands. That felt like a small app problem, not a big framework problem.

What SSHFS GUI does

Save servers — host, port, remote path, local mount point, auth method
One-click mount/unmount — still real sshfs under the hood
Keychain — passwords via keytar, never in plain JSON
SSH agent, key file, or password
Favorites & filters — all / favorites / mounted
Auto-mount on startup — per server
Menu bar mode — tray access in packaged builds
Import/export — move configs between Macs as JSON
EN + IT — i18next, system locale detection

The app also checks for missing FUSE/sshfs and points you to Homebrew install steps if something's missing.

Install FUSE + sshfs (once)

Pick one stack:

Option A — FUSE-T (no kext, often easiest on recent macOS):

brew tap macos-fuse-t/homebrew-cask
brew install --cask fuse-t fuse-t-sshfs

Option B — macFUSE (classic stack):

brew install --cask macfuse
brew install gromgit/fuse/sshfs-mac

On some FUSE-T setups, Finder needs extra flags (e.g. -o nonamedattr). You can add those in the app's SSHFS extra options field per server.

Install the app

Download the signed DMG from GitHub Releases
Drag SSHFS GUI to Applications
Add a server → Mount → open in Finder

Source: github.com/tommasomeli/sshfsgui

How it's built

Solo side project, shipped with CI and notarized macOS builds.

Layer	Choice
Shell	Electron 41
Build	electron-vite + Vite
UI	React 19, TypeScript, Tailwind, shadcn/ui
State	Zustand
Secrets	keytar → macOS Keychain
i18n	i18next (EN / IT)
Tests	Vitest (path handling, import/export, sshfs args)
Release	GitHub Actions → signed + notarized DMG

Interesting bits for fellow Electron devs:

Import/export logic lives in src/shared/ so Vitest runs on Linux CI without loading keytar
Tray menu uses the same i18n keys as the app menu — easy to miss the { name: appInfo.name } interpolation on quit
prebuild icon script skips on non-macOS so CI can electron-vite build on Ubuntu

What it's not

Not a replacement for Cyberduck or full SFTP workflows
Not "FUSE-free" — you still need FUSE-T or macFUSE + sshfs, same as CLI
Not cross-platform today — macOS only

Try it / feedback

Download: https://github.com/tommasomeli/sshfsgui/releases
Repo: https://github.com/tommasomeli/sshfsgui
Issues & feature requests: GitHub issue templates welcome

I'd especially love to hear from anyone running FUSE-T vs macFUSE on Tahoe — mount stability after sleep is the edge case I care about most.

If you have a cleaner Mac sshfs workflow, tell me in the comments. Always looking to steal good ideas for v1.1.