DEV Community: Nathmaxx

Convert a whole folder of images to WebP — locally, no upload, one command

Nathmaxx — Sat, 11 Jul 2026 07:40:47 +0000

Every few months I hit the same wall: a folder full of .jpg and .png files that need to be WebP before they go anywhere near production. And every few months I catch myself doing the dumbest possible thing — dragging them one by one into some online converter, waiting for the upload, downloading them back, renaming them.

It doesn't scale, and honestly I'm never thrilled about uploading a client's assets to a random SaaS just to save a few kilobytes.

So the workflow below does the whole folder in one command, locally — nothing leaves your machine, no account, originals left untouched. It runs on @assetopt/cli (open source, MIT), a small CLI I've been building that optimizes images and CSS, JS and SVG in one pass.

Why WebP at all

WebP is typically 25–35% smaller than an equivalent JPEG or PNG at matched quality. It's one of the cheapest wins available for page weight — the format is universally supported now, and the only friction left is doing it in bulk without a painful workflow.

Install

npm install -g @assetopt/cli

Or run it once, without installing anything:

npx @assetopt/cli --help

The one-command version

Point assetopt at a folder and it recurses into it. By default it recompresses images in their original format — to turn JPG and PNG into WebP, you say so once in a config file.

Create a .assetoptrc that routes both source formats to WebP:

{
  "images": {
    "formatMatrix": { "jpeg": "webp", "png": "webp" },
    "quality": { "webp": 82 }
  },
  "output": { "dir": "./optimized" }
}

Then convert the folder:

assetopt optimize ./images

Every .jpg and .png under ./images is written as .webp into ./optimized, mirroring the source tree. Your originals stay exactly where they are.

Preview the savings before touching your disk

This is the part I actually use the most. analyze reports the exact before/after sizes as a dry run — it writes nothing:

assetopt analyze ./images

You get a per-file table and a total. When the numbers look right, swap analyze for optimize.

Tune the quality, fast

WebP quality is a 1–100 dial (default 82). Lower means smaller files and more visible artifacts:

{ "images": { "formatMatrix": { "jpeg": "webp", "png": "webp" }, "quality": { "webp": 75 } } }

Re-run assetopt analyze ./images after each change. There's an incremental cache on by default, so only the files you actually changed get re-encoded — tuning the quality dial is basically instant instead of re-crunching the whole folder each time.

Real numbers

Running the config above on a sample pack (JPG/PNG → WebP):

Source	Before	After (WebP)	Saved
Large PNG export (opaque photo)	5.42 MB	552 KB	−89.8%
JPEG photo	1.74 MB	1.44 MB	−17.4%

The PNG loses the most, because a photo saved as PNG is hugely oversized to begin with — WebP is simply the right container for it. A photo already saved as JPEG is closer to optimal, so the win is smaller but still real. You can reproduce these exact figures by downloading the pack and running the commands above.

When WebP isn't the best target

For transparent PNGs (logos, icons), AVIF often keeps the alpha channel at a smaller size than WebP. assetopt can route by content — opaque → WebP, transparent → AVIF — automatically.

That's the whole loop: preview, convert, done — locally, no upload. If you want the full write-up (config reference, wiring it into a build step, the CI quality gate), it lives here:

👉 Convert JPG & PNG to WebP in bulk — the full guide

If you give it a spin I'd genuinely like to hear what savings you get on your own assets — drop a comment.

Stop writing TypeScript interfaces by hand - generate them from JSON, CSV, and OpenAPI in one command

Nathmaxx — Fri, 08 May 2026 07:55:01 +0000

You're integrating a third-party API. You open the docs, find a sample response, and start typing:

interface Product {
    id: number;
    name: string;
    price: number;
    // wait, is currency a string or an object?
    // what's the shape of variants[]?
    // does stock ever go null?
}

Twenty minutes later you have a fragile interface you're not fully confident in — and the moment the API ships a new field, it's already stale.

There's a better way.

snaptype: point it at the source, get types back

snaptype is a CLI that generates TypeScript interfaces and Zod schemas by reading your actual data — live API endpoints, OpenAPI specs, JSON files, CSV files.

No config. No code to write. One command.

`from-url` — types straight from a live endpoint

This is the one I use most. Give it any JSON endpoint:

npx snaptype from-url https://api.example.com/products --zod -o src/types/product.ts

snaptype fetches the response and generates:

export interface Product {
    id: number;
    name: string;
    price: number;
    currency: "USD" | "EUR" | "GBP";
    stock: number | null;
    createdAt: string;
    variants: Variant[];
}

export interface Variant {
    sku: string;
    color: string;
    size: "S" | "M" | "L" | "XL";
}

export const ProductSchema = z.object({
    id: z.number(),
    name: z.string(),
    price: z.number(),
    currency: z.enum(["USD", "EUR", "GBP"]),
    stock: z.number().nullable(),
    createdAt: z.iso.datetime(),
    variants: z.array(VariantSchema),
});

A few things worth noticing:

Nested objects are expanded — variants[] became its own Variant interface automatically
Enums are inferred — currency and size had a small set of repeated values, so snaptype made them union types instead of string
Nullables are detected — stock was null in some responses, so it became number | null
Semantic types — createdAt became z.iso.datetime(), not a generic z.string()

This is inference against real data, not a naive field-by-field mapping.

Real-world example: GitHub API

Point it at any real endpoint — here the GitHub user API:

npx snaptype from-url https://api.github.com/users/torvalds --zod -o src/types/github-user.ts

Done. You now have typed access to every field in that response — including nested objects — with Zod schemas you can use directly for runtime validation.

When GitHub ships a new field, re-run the command. No manual diffing.

`from-openapi` — one file per schema, from any spec

If the API you're integrating has an OpenAPI or Swagger spec (most do), this is even better. Point it at the spec file:

npx snaptype from-openapi ./openapi.yaml -o src/types/

Or directly at the hosted spec URL:

npx snaptype from-openapi https://petstore3.swagger.io/api/v3/openapi.json -o src/types/

snaptype reads every schema definition in the spec and generates one typed file per schema. YAML and JSON both work.

For a spec that defines Pet, Order, and User, you get three files:

// src/types/Pet.ts
export interface Pet {
  id?:        number;
  name:       string;
  photoUrls:  string[];
  status?:    "available" | "pending" | "sold";
  tags?:      Tag[];
  category?:  Category;
}

// src/types/Order.ts
export interface Order {
  id?:        number;
  petId?:     number;
  quantity?:  number;
  shipDate?:  string;
  status?:    "placed" | "approved" | "delivered";
  complete?:  boolean;
}

Before, setting up a typed client from an OpenAPI spec meant:

Finding (or writing) a code generator
Configuring it
Running it
Cleaning up the generated mess
Updating it every time the spec changes

Now it's one command.

Works with private and authenticated APIs

One-off request — pass headers directly with -H:

npx snaptype from-url https://api.example.com/me \
  -H "Authorization: Bearer $TOKEN" \
  --zod -o src/types/me.ts

Multiple endpoints on the same API — store the headers in .snaptyperc so you don't repeat yourself:

{
    "baseUrl": "https://api.example.com",
    "headers": {
        "Authorization": "Bearer my-token",
        "X-Tenant": "acme"
    }
}

Then every from-url call picks them up automatically:

npx snaptype from-url /users -o src/types/user.ts
npx snaptype from-url /products -o src/types/product.ts
npx snaptype from-url /orders -o src/types/order.ts

Headers set in .snaptyperc are defaults — anything passed with -H on the CLI takes priority if the same key appears in both.

stdin fallback — if the endpoint requires a flow you can't replicate in a single request (custom auth, cookies, proxy), pipe the response in from curl:

curl -s -H "Authorization: Bearer $TOKEN" https://api.example.com/me \
  | npx snaptype from-stdin --zod -o src/types/me.ts

JSON files and CSV too

If you're working from a local file rather than a live endpoint:

# Local JSON file
npx snaptype from-json ./user.json --zod -o src/types/user.ts

# CSV export from a database or spreadsheet
npx snaptype from-csv ./orders.csv --zod -o src/types/order.ts

The inference is the same — enums, nullables, semantic types, nested objects.

Zero config to start

No setup needed. If you want to pin defaults, add a .snaptyperc:

{
    "zod": true,
    "outDir": "src/types"
}

Then every command just picks up those defaults automatically.

Try it right now

Run it directly with npx — no install needed:

npx snaptype from-url https://api.github.com/users/torvalds --zod -o src/types/github-user.ts

Or add it as a dev dependency if you want a fixed version and faster runs:

npm install -D snaptype
snaptype from-url https://api.github.com/users/torvalds --zod -o src/types/github-user.ts

Full docs at snaptype.dev · Source on GitHub.

If it saves you time, a ⭐ on the repo goes a long way — it helps other developers find the tool.

Built this after one too many mornings spent re-typing interfaces from API docs. If from-url or from-openapi saves you time on a real project, drop a comment — I'm curious what APIs people are working with.

Feedback welcome

snaptype is still early-stage and I'm actively shaping what it becomes. If you hit a use case it doesn't handle, a command that behaves unexpectedly, or a feature you'd find genuinely useful — open an issue on GitHub or just leave a comment below. Every piece of feedback helps.