Forem: Steve Lebleu

Agnostic email sending in Node.js

Steve Lebleu — Sat, 25 Apr 2026 08:33:30 +0000

The Cliam package is back on track with a serious update about the quality, the dX, the flexibility and the security.

For those ones that are not aware of what Cliam can achieve for them (and believe me, he can), just a short trailer:

One input. One output. Any provider. Now more than ever.

And some number that matters

10 providers. 1 interface. 0 new runtime dependencies in v3.

Pick your provider. Switch tomorrow. Your code doesn't care.

import { Cliam } from 'cliam';

Cliam.mail('user.welcome', payload); // always the same

The last marketing post is here. Let's quickly deep dive into the v3 release logs.

New providers

Two heavy hitters join the roster.

Resend - the developer-first email API built for the modern stack. Clean, predictable, fast.

Amazon SES - enterprise-grade deliverability at AWS scale. And because we know you hate unnecessary dependencies: SES authentication (AWS Signature V4) is implemented natively using Node.js built-in crypto. No @aws-sdk. No bloat. Zero new runtime dependencies.

Stack upgraded

Cliam now runs on TypeScript 6. ESM all the way, moduleResolution: Bundler, built with tsup. No CommonJS cruft, no compatibility shims.

The toolchain got a pass too: Biome 2.x handles linting and formatting, Bun runs the test suite, and tsc --noEmit is wired in as a dedicated typecheck script so your IDE and your CI agree on what's broken.

DX improved

The API surface got cleaner.

inlineImages is gone. It was never doing what you thought it was. Use content attachments like everyone else.
sendinblue is also gone. It was Brevo. It's still Brevo. Update your config: provider: 'brevo'.
Template IDs now live exclusively on the transporter configuration, not scattered across options. One place, one source of truth.
Theme colors are now injected as named Handlebars variables (primaryColor, secondaryColor, …) instead of post-render hex string replacement. Predictable. Debuggable. Actually makes sense.

Security improved

56 vulnerabilities. Including criticals. Now 0.

The previous architecture routed all providers - including HTTP API ones - through nodemailer, dragging along its entire dependency tree. That tree was old, wide, and full of known CVEs.

v3 cuts it at the root. HTTP API providers (Brevo, Mailersend, Mailgun, Mailjet, Mandrill, Postmark, Resend, Sendgrid, SES, Sparkpost) now talk to their APIs through our own thin HttpClient wrapper built on ky. Nodemailer stays for SMTP - but only for SMTP, pinned to its latest maintained release (v8), with a clean bill of health.

Less surface. Less trust. Less exposure.

The rest of the security picture:

AWS SES requests are signed per-request using a proper Signature V4 implementation: timestamp, payload hash, HMAC chain, the works. No pre-shared static tokens flying around.
All provider API key formats are validated at configuration time with provider-specific Joi regexes. You know immediately if something is wrong, not when your first email fails at 2am.
Sandbox mode remains a hard gate: nothing leaves the process when it's on.

Type system cleaned up

The internal type system went through a full consistency pass.

Enums replaced with as const objects + derived union types - one source of truth, no parallel declarations.
IMail.meta is now narrowed: from and replyTo are required by the type, not just by convention.
Body interfaces defined per provider, ready to be wired into build() return types for full end-to-end type coverage.

Bundle size improved

Before v3, import { Cliam } from 'cliam' silently loaded every provider, all ten of them, their HTTP clients, their payload mappers, all of it. You used Brevo. You got Sparkpost too. And Mailjet. And the rest.

Now providers are tree-shakeable. Import everything at once, or load only what you actually ship:

import { Cliam } from 'cliam/core';
import 'cliam/providers/brevo'; // that's it

Your bundler sees exactly what you use. Nothing more makes it into your artifact.

Types improved

The public API is now fully typed and fully exported. Consumers get first-class access to every interface they need:

import type { IPayload, IClientConfiguration, IAddressable, IAttachment } from 'cliam';

No more reaching into internals. No more any patches at the call site. Your IDE knows what meta.from is. Your compiler catches the typo before you do.

Configuration improved

Two modes, your choice, no process assassination.

// Programmatic — config lives in your code
Cliam.configure({ sandbox: true, transporters: [...] });

// File-based — config lives in .cliamrc.js
Cliam.configureFromFile('/path/to/config.js');

The critical part: bad configuration used to call process.exit(). Your app just died, silently, in the middle of startup, with a log line you may or may not have seen. That's gone. Configuration errors now throw, which means you catch them, you log them your way, you decide what happens next. Your process is yours again.

Thanks for the reading, enjoy your dev, and see you there:

npmjs.com

steve-lebleu / cliam

Agnostic transactional email sending in Node.js environment

Transactional emails with a kick

Agnostic transactional email sending in Node.js environment

> Why ?

To improve and facilitate the implementation, the flexibility and the maintenance of transactional emailing tasks.

> Features

Agnostic transactional email sending using web API or SMTP server. One input, one output.
Multiple simultaneous transporters.
Configuration based, not implementation based: easy switch between different modes.
Normalized transactions events.
Securized payloads.
Customisable default templates.

> Table of contents

> Requirements

Node.js >= 18.19.0
NPM >= 10.2.3

> Getting started

Install

> npm i cliam --save

Configure

Cliam must be configured once at application startup, before any call to mail(). Two approaches are available.

Option A - Pass a configuration object directly:

import { Cliam } from 'cliam';
import type { IClientConfiguration } from 'cliam';

…

View on GitHub

VoidZero is driving the unification of the JS ecosystem

Steve Lebleu — Sat, 21 Mar 2026 13:24:38 +0000

VoidZero launch week is drawing to a close, and the world of Javascript development has just been given a significant boost. If you follow developments in build tools, you’ll know that fragmentation is rife, and that it’s difficult to stay at the cutting edge without using the best tool for each task. With the latest announcements regarding Vite, Oxlint and Vitest, Evan You team is taking a major step towards the goal of unifying everything to improve performance and simplicity.

Here are the key takeaways from this wave of updates.

Oxlint: no more trade-offs between speed and compatibility

Until now, choosing Oxlint meant sacrificing the ESLint plugin ecosystem in favour of Rust’s performance.

That is no longer the case: Oxlint has reached a major milestone with its JS Plugins Alpha.

In fact, your ESLint plugins now run in Oxlint without any modifications, with execution speeds up to 100 times faster than with ESLint. And as the folks at Void are so helpful, they’ve provided a migration tool (@oxlint/migrate) that allows for an automatic transition from your existing configuration.

Suffice to say that following the arrival of Biome.js, competition is becoming very, very fierce for ESLint, which has historically always suffered from limitations in execution, configuration and compatibility. It’s a drop-in replacement for around 80% of users, already adopted by major projects such as Preact and PostHog.

One bundler to rule them all with Vite 8 and Rolldown

This is undoubtedly the most significant architectural change. Vite 8 is moving away from the esbuild (dev) / Rollup (prod) combination in favour of Rolldown, its new bundler, which is also written in Rust.

In practical terms, what does this mean?

Firstly, a clear unification between your local build and your production build. No more surprises or inconsistencies between your environments.

Secondly, well – thanks to Rust – builds are 10 to 30 times faster than with Rollup. For example, the teams at Linear reportedly saw their build times drop from 46 seconds to 6 seconds, which is quite significant.

Finally, the bundler now natively supports tsconfig paths and decorators, and offers a new, much more flexible codeSplitting API. A breath of fresh spring air, as they say.

More stability and less “flaky tests” at Vitest side

Vitest 4.1 keeps pace with native support for Vite 8 and features designed for large-scale projects.

Anyone who has written tests for an asynchronous application knows the drill: they leak, they hang left, right and centre, and they’re often difficult to debug. Vitest now offers asynchronous leak detection to put an end once and for all to the timers that clutter up workflows.

In addition, you can now assign tags to your test suites to organise them more effectively. It’s not the most groundbreaking update, but it can be useful for large codebases.

Finally, VoidZero is already anticipating new development workflows by equipping Vitest with a “reporter agent”, an output optimised for AI coding agents.

Towards a “Zero Config” experience

The project goes beyond individual tools. The aim is to cover the entire application lifecycle to provide a complete value chain.

Vite+ (Alpha) centralises everything via a single binary called vp. It acts as a task orchestrator with a persistent cache. No need to configure ESLint, Prettier or Vitest separately! A single vite.config.ts file drives the entire toolchain.

This makes setup very simple:

vp create generates a new project
vp dev starts the development server
vp check performs linting, formatting and type checking in a single line
vp test runs tests using Vitest,
vp build creates an optimised production build,
vp run orchestrates monorepo tasks

Void, the deployment platform announced by Evan You, brings things full circle by offering an Infrastructure-as-Code approach, where the Void SDK analyses your code to automatically provision the necessary resources (DB, Auth, AI inference). And it doesn’t stop there, as the platform offers native support for the MCP protocol: developers can now not only write your code, but also autonomously set up and deploy the infrastructure on Void.

Key takeaways

The Javascript ecosystem is emerging from a (long) period of having a “scattered toolkit” to now natively integrate linting, testing, building and deployment under a single technological umbrella (Rust + Vite).

VoidZero offers a super-smooth developer experience, where performance comes as standard.

They are not the only ones heading in this direction – Biome springs to mind – but they provide a more comprehensive solution that will significantly improve business workflows and influence the ecosystem.

To find out more, you can consult the official migration guides on the VoidZero blog or explore the Vite 8 documentation.

This article has been translated from french original publication VoidZero pousse l'unification de l'écosystème Javascript

Email sending in Node.js

Steve Lebleu — Thu, 22 Feb 2024 16:34:25 +0000

As a developer, email sending is a recurent task across the projects.

Most part of time, you have to deal with open source libraries, to switch from a library to another accross the projects, with some particular implementations and / or behaviors.

As well, you can have a different need inside a same project just regarding the use case.

For example, you can still need to send an email to a developer when a particular event is fired, or send a transactionnal email to say welcome to a new user.

In the first case, a simple SMTP server can do the job internally.

In the second case, it's more efficient to rely to a web API, able to manage statistics, bouncing, DKIM, templating, ...

As well, you can need to deal with different providers at the same time. During a migration, for example.

Some months ago, I was wondering how to provide something flexible and consistent to deal with this kind of repetitive issue.

And I did it myself, because it was quite fun. 😎

All the cases described above - and some others - are covered by a light NPM package.

The main features are:

Configuration based
Agnostic appoach: same input, same output for all configurations
Formalized transactions conventions
Unlimited number of transporters inside the same project
Support of different sending modes (SMTP and web API)
Embeded view engine, stream or web API templates

There is Cliam, an agnostic and very flexible tool to deal with transactional email sending.

steve-lebleu / cliam

Agnostic transactional email sending in Node.js environment

Transactional emails with a kick

Agnostic transactional email sending in Node.js environment 💥 💪 💊

> Why ?

To improve and facilitate the implementation, flexibility and maintenance of transactional emailing tasks.

> Features

Agnostic transactional email sending using web API or SMTP server. One input, one output.
Multiple simultaneous transporters.
Configuration based, not implementation based : easy switch between different modes.
Normalized transactions events.
Securized payloads.
Customisable default templates.

> Table of contents

> Requirements

Node.js >= 18.19.0
NPM >= 10.2.3

> Getting started

Install

> npm i cliam --save

Configure

Create a .cliamrc.js module on the root of your project.

> touch .cliamrc.js

Define a minimalist configuration in .cliamrc.js newly created:

module.exports = {
  "sandbox": true,
  "transporters": [
    {
      "id": "unique-transporter-key",
      "auth": {
        "username": process

…

View on GitHub

Currently, following web api providers are supported: Mailgun, Mailjet, Brevo, Sendinblue, Sendgrid, Mandrill, Sparkpost, Mailsender and Postmark. Amazon SES and a lot of others should be integrated soon, but I prefer take the focus on some new features and to push more robustness before to embedd too much transporters.

Have a good dev, enjoy and feel free to use and to share 🚀