DEV Community: Cris Mihalache

Using Chat GPT To Generate Datasets 🤖

Cris Mihalache — Thu, 23 Apr 2026 00:53:30 +0000

Recently I used Chat GPT to generate mock data in JSON format.

This is extremely powerful, as you can describe what real data looks like in your prompt, and Chat GPT will generate data with realistic content in fields like descriptions, titles, tags, etc.

This is a sample of the data Chat GPT generated:

  {
    "id": 3,
    "description": "Implementing OAuth2 for user authentication",
    "tags": [
      "@feature",
      "@security"
    ],
    "start": "2024-02-22T03:11:03",
    "end": "2024-02-22T06:36:18"
  }

Notice how the description, tags, and duration are all realistic.

Example

To build the documentation website for track-time-cli, I needed a database with mock data to have realistic command output in the documentation content.

To get Chat GPT to generate them for me, I used the following prompt:

Generate 5 time sheet entries with realistic software development tasks as descriptions. Use the following schema:

        {
          "id": 1,
          "description": "writing documentation",
          "tags": [
            "@feature",
            "@docs"
          ],
          "start": "2024-02-21T18:26:45",
          "end": "2024-02-21T19:33:08"
        }

The entries should be sequential in time, of varying durations (between 5 minutes and 5 hours), and have realistic descriptions that fit the software development time sheet theme.

The output should be in JSON, an array of time sheet entries conforming to the provided schema example.

Note that I specified the number of entries (5) and the type of activity (realistic software development tasks) that should be mentioned in the description.

I defined the output schema by providing an example of a correctly formatted time sheet entry. I also specified that they should be sequential in time and have realistic durations as would be expected for the defined type of activity.

Result

This was the output:

[
  {
    "id": 1,
    "description": "Refactoring user interface code",
    "tags": [
      "@feature",
      "@frontend"
    ],
    "start": "2024-02-21T18:26:45",
    "end": "2024-02-21T22:39:32"
  },
  {
    "id": 2,
    "description": "Optimizing database queries for report generation",
    "tags": [
      "@performance",
      "@database"
    ],
    "start": "2024-02-21T22:39:32",
    "end": "2024-02-22T03:11:03"
  },
  {
    "id": 3,
    "description": "Implementing OAuth2 for user authentication",
    "tags": [
      "@feature",
      "@security"
    ],
    "start": "2024-02-22T03:11:03",
    "end": "2024-02-22T06:36:18"
  },
  {
    "id": 4,
    "description": "Weekly team sync-up meeting",
    "tags": [
      "@meeting",
      "@communication"
    ],
    "start": "2024-02-22T06:36:18",
    "end": "2024-02-22T10:16:24"
  },
  {
    "id": 5,
    "description": "Adding localization support for new languages",
    "tags": [
      "@feature",
      "@i18n"
    ],
    "start": "2024-02-22T10:16:24",
    "end": "2024-02-22T11:50:10"
  }
]

After running this prompt a few times to generate 16 entries, I placed them all in an array within a mock JSON database. The output of running track-time-cli's list command was the following:

 23:50 ▶ 97% ▶ xia ▶ f3rnox ▶ .track-time-cli ▶  main ▶ ✎ ▶ 2? ▶ $ ▶ tt l
* Showing sheets since 2/21/2024, 12:00:00 AM [yesterday]

- Sheet main (16 entries) [1:10:19:16]
    (1)   [9:28:26]  yesterday       ->  14 hours ago    Writing API documentation                           @feature @docs
    (2)   [16:51]    14 hours ago    ->  14 hours ago    Implementing user authentication module             @feature @backend
    (3)   [50:01]    14 hours ago    ->  13 hours ago    Designing database schema for new features          @design @database
    (4)   [2:04:11]  13 hours ago    ->  11 hours ago    Improving responsive design for mobile devices      @feature @frontend
    (5)   [2:29:48]  11 hours ago    ->  9 hours ago     Conducting user experience research                 @research @ux
    (6)   [1:42:30]  9 hours ago     ->  7 hours ago     Implementing caching for improved performance       @performance @backend
    (7)   [9:08]     7 hours ago     ->  7 hours ago     Weekly team retrospective meeting                   @meeting @team
    (8)   [39:52]    7 hours ago     ->  6 hours ago     Refining search algorithm                           @algorithm @backend
    (9)   [2:13:23]  6 hours ago     ->  4 hours ago     Reviewing and merging pull requests                 @review @version-control
    (10)  [1:08:12]  4 hours ago     ->  3 hours ago     Developing new feature for customer analytics       @feature @analytics
    (11)  [2:27:32]  3 hours ago     ->  21 minutes ago  Solving compatibility issues in cross-platform app  @bugfix @mobile
    (12)  [3:14:14]  21 minutes ago  ->  in 3 hours      Organizing backlog and prioritizing tasks           @planning @management
    (13)  [3:07:36]  in 3 hours      ->  in 6 hours      Upgrading server infrastructure                     @maintenance @devops
    (14)  [1:41:17]  in 6 hours      ->  in 8 hours      Creating automated tests for new API endpoints      @testing @automation
    (15)  [2:02:29]  in 8 hours      ->  in 10 hours     Troubleshooting server downtime issues              @maintenance @devops
    (16)  [43:46]    in 10 hours     ->  in 10 hours     Designing user interface for the upcoming module    @design @frontend

* 0 Sheets not shown. use --all to show

Conclusions

Clearly Chat GPT is a great tool for generating realistic datasets.

Try it out the next time you need some mock data with realistic textual content! 🚀

Build a typed CLI from scratch with Commander.js + Zod

Cris Mihalache — Wed, 22 Apr 2026 23:03:34 +0000

The problem with untyped CLIs

Commander.js is great for parsing arguments, but it hands you everything as string | undefined — regardless of what type you declared in the option definition. The <number> in .option("--count <number>") is cosmetic. What lands in your action handler is raw text from process.argv, and the coercion, validation, and type-narrowing is entirely on you. Most developers paper over this with parseInt(opts.count as string) and hope for the best. That works until a user passes "banana" and your tool crashes with a stack trace instead of a helpful message.

We already have the right tool for this: Zod. It's everywhere in the Node.js ecosystem for HTTP bodies, env vars, and config files — but rarely applied at the CLI layer. That's the gap this post fills. By the end you'll have a CLI that validates all inputs at the boundary, gives users readable error messages, and is fully typed end-to-end with no casts and no any.

1. Project scaffold

mkdir my-cli && cd my-cli
npm init -y
npm install commander zod
npm install -D typescript tsx @types/node
npx tsc --init

Three dependencies: commander for the CLI surface, zod for validation, tsx to run TypeScript directly during development without a compile step. Update tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "dist"
  }
}

strict: true is non-negotiable here — it's exactly what catches the class of bugs we're solving. Wire up bin and scripts in package.json:

{
  "bin": { "my-cli": "./dist/index.js" },
  "scripts": {
    "dev": "tsx src/index.ts",
    "build": "tsc"
  }
}

2. Your first typed command

import { Command } from "commander";

const program = new Command();

program
  .name("my-cli")
  .option("--name <string>", "Your name")
  .option("--count <number>", "How many times to greet")
  .action((opts) => {
    console.log(opts);
  });

program.parse(process.argv);

Run it:

npx tsx src/index.ts --name Alice --count 3
# { name: 'Alice', count: '3' }

count is '3' — a string. Commander doesn't coerce types. If you do arithmetic with it you get string concatenation. If you type-guard with typeof opts.count === 'number' it always returns false. This is the gap Zod fills.

3. Enter Zod — schema-validate your options

Treat program.opts() the same way you'd treat an untrusted HTTP request body: validate at the boundary, only work with the parsed output. Define a schema and run opts through it:

import { z } from "zod";

const OptionsSchema = z.object({
  name: z.string().min(1, "Name cannot be empty"),
  count: z.coerce.number().int().positive().default(1),
});

program.action((opts) => {
  const options = OptionsSchema.parse(opts);

  for (let i = 0; i < options.count; i++) {
    console.log(`Hello, ${options.name}!`);
  }
});

z.coerce.number() calls Number(value) before validating, converting Commander's "3" to 3. If someone passes --count banana, Zod rejects it cleanly instead of silently producing NaN. .int().positive() enforces additional constraints without a single if statement. .default(1) makes the option optional — Zod fills it in. After .parse(), options has the inferred type { name: string; count: number } — no annotation required.

4. User-friendly validation errors

Right now a failed parse throws a raw ZodError JSON blob at the user. Fix that with a small reusable helper using safeParse():

import { ZodSchema } from "zod";

function parseOptions<T>(schema: ZodSchema<T>, opts: unknown): T {
  const result = schema.safeParse(opts);

  if (!result.success) {
    console.error("Invalid options:\n");
    result.error.issues.forEach((issue) => {
      console.error(`  --${issue.path.join(".")}  ${issue.message}`);
    });
    console.error("\nRun with --help for usage.\n");
    process.exit(1);
  }

  return result.data;
}

Before vs after, when --name is missing:

# Before
ZodError: [{"code":"too_small","path":["name"],"message":"Name cannot be empty"...}]

# After
Invalid options:

  --name  Name cannot be empty

Run with --help for usage.

This helper is generic — T is inferred from the schema, so the return type is always exactly right. opts is unknown, which correctly models the untrusted input. Replace all direct .parse() calls with parseOptions(schema, opts) going forward.

5. Scaling to subcommands

As your CLI grows, each command gets its own schema and calls the same helper — no copy-pasted validation logic:

const InitSchema = z.object({
  dir: z.string().default("."),
  force: z.boolean().default(false),
});

const RunSchema = z.object({
  name: z.string().min(1),
  count: z.coerce.number().int().positive().default(1),
});

program
  .command("init")
  .option("--dir <path>", "Target directory")
  .option("--force", "Overwrite existing files")
  .action((opts) => {
    const options = parseOptions(InitSchema, opts);
    console.log(`Initializing in ${options.dir}`);
  });

program
  .command("run")
  .option("--name <string>", "Your name")
  .option("--count <number>", "How many times to greet")
  .action((opts) => {
    const options = parseOptions(RunSchema, opts);
    for (let i = 0; i < options.count; i++) {
      console.log(`Hello, ${options.name}!`);
    }
  });

Inside the init action, options has type { dir: string; force: boolean }. Inside run, it's { name: string; count: number }. TypeScript infers these separately from each schema — accessing options.name in the init handler is a compile error, not a runtime surprise.

6. Help menus and `.env` support

Commander generates --help automatically from your .option() descriptions — you already have it for free. One gotcha: Zod's .default() values don't appear in Commander's help output. Mirror them manually in the third argument to .option():

.option("--count <number>", "How many times to greet", "1")

For .env support, merge environment variables into opts before parsing. Zod doesn't care where values originate — it just validates the final object:

import "dotenv/config";

program.command("run").action((cliOpts) => {
  const merged = {
    name: process.env.CLI_NAME,
    count: process.env.CLI_COUNT,
    ...cliOpts, // CLI flags win over env vars
  };
  const options = parseOptions(RunSchema, merged);
});

Env vars as defaults, CLI flags as overrides — one schema validates both.

7. Publishing to npm

Add a shebang as the very first line of src/index.ts (before imports):

#!/usr/bin/env node

Build, make the output executable, test locally with npm link, then publish:

npm run build
chmod +x dist/index.js
npm link
my-cli run --name Cris --count 3  # test it
npm unlink my-cli
npm publish --access public

Verify with npx my-cli run --name Cris --count 3 — if that works, you're done.

Wrapping up

The pattern in one line: Commander owns the surface, Zod owns the contract. Commander parses and routes. Zod coerces, validates, defaults, and types. The parseOptions helper — 15 lines — is the glue, and it scales to any number of subcommands without modification.

This isn't CLI-specific either. The same schema-at-boundary approach applies to HTTP bodies, env vars, and config files. Validate everything at every input boundary, work only with validated data inside your logic, and an entire category of runtime bugs stops existing.

The full source is on GitHub: [link to your repo]

Next up: adding --json output mode and stdin piping so your CLI composes cleanly in shell pipelines.

Found this useful? Drop a reaction or leave a comment — feedback helps me prioritise what to cover next in this series.

Stop Guessing npm Package Names — Let a CLI Do It

Cris Mihalache — Wed, 22 Apr 2026 22:32:04 +0000

You've finished building a neat little utility. You open a terminal, type npm publish, and then… stall. What do you name the thing?

You try json-stream-parser — taken. stream-json-parser — also taken. parse-json-stream — taken too, and it's a completely different package. You spend 20 minutes bouncing between the npm registry website and your terminal before settling on something you're not even happy with.

I've been through that loop more times than I'd like to admit, so I built a small tool to short-circuit it: gen-package-name.

What it does

gen-package-name is a CLI utility that:

Asks you for a short description of your package (or accepts keywords directly)
Extracts meaningful keywords from that description
Generates a set of name candidates using those keywords
Checks each candidate against the npm registry in real time
Lets you regenerate until you find something you like

The whole flow takes about 30 seconds.

Getting started

Install globally:

npm install -g gen-package-name

Or just run it once with npx:

npx gen-package-name

Interactive mode (the happy path)

Run it with no arguments and it walks you through everything:

gen-package-name

You'll be prompted for a description like "parse json streams efficiently". It strips stop words, extracts the signal (parse, json, streams), and generates 5 name candidates using a mix of patterns — adjective-noun, verb-noun, noun-type, and combinations like verb-keyword-cli. Each candidate gets checked against the registry and marked available or taken.

If you don't love the batch, you can regenerate as many times as you want. When you pick a name that's already taken, it fetches and prints the existing package's metadata so you know what you're up against.

Non-interactive and CI-friendly modes

For scripting and pipelines, there are a few flags worth knowing:

Generate names from a description, no prompts:

gen-package-name -d "http request retry logic" -n

Pass keywords directly, show only available names, output JSON:

gen-package-name -k http,retry,fetch -c 10 -a -j

The JSON output is machine-readable, so you can pipe it into other tools or use it in a script that automates your publish workflow.

Quick availability check for a specific name:

gen-package-name --check my-package-name

Fetch registry metadata for any existing package:

gen-package-name --info chalk --json

How the name generation works

The generator builds name candidates by randomly combining words from several pools:

Adjectives — words like tiny, fast, safe, sharp
Verbs — words like parse, watch, build, resolve
Nouns — a curated list plus your own keywords injected at the top
Package type suffixes — lib, cli, kit, util, core, and so on

The patterns it uses are the same conventions that popular npm packages already follow: adjective-noun (tiny-emitter, fast-glob), verb-noun (parse-json, watch-config), and noun-type (router-kit, cache-lib). When you supply two or more keywords, it also generates keyword-keyword pairs — things like http-client or auth-token — which tend to be the most memorable names.

Candidates are validated against npm's naming rules before they're even checked against the registry (lowercase alphanumeric and hyphens, no leading/trailing hyphens, max 214 chars), so you never get back something that would fail at publish time anyway.

Full CLI reference

Usage: gen-package-name [options]

Options:
  -V, --version          print version and exit
  -d, --description      describe the package (keywords extracted automatically)
  -k, --keywords <list>  comma- or space-separated keyword seeds
  -c, --count <n>        number of names to generate (default: 5)
  -a, --available-only   only output names available on npm
  -j, --json             emit machine-readable JSON
  -n, --non-interactive  skip prompts; print results and exit
  --check <name>         check whether a specific name is available
  --info <name>          fetch npm registry metadata for a package
  --no-color             disable colored output
  -h, --help             display help

Stack

The package is written in TypeScript, targets Node.js ≥ 16, and uses:

Commander.js for argument parsing
Inquirer for the interactive prompts
chalk for colored output
package-json to query the npm registry

No exotic dependencies, no network calls beyond the registry lookups.