feat: replace commander with @takojs/tako

[kitaharata]

Last Modified: 2025-11-26

Hello Hono contributors,

This PR replaces commander with @takojs/tako.

https://takojs.github.io/

Although Issue #42 was already closed, this change addresses the original problem.
As yusukebe said:

It will be a good idea to create a library that supports multiple runtimes, not only Node.js, outside of github.com/honojs. If so, we can use it in this honojs/cli.

As a result of this work, the CLI now uses @takojs/tako.

Terminal commands used during migration

$ bun remove commander
$ bun add @takojs/tako

$ bun run build
$ tsup
CLI Building entry: src/cli.ts
CLI Using tsconfig: tsconfig.json
CLI tsup v8.5.0
CLI Using tsup config: /workspaces/cli/tsup.config.ts
CLI Target: es2022
CLI Cleaning output folder
ESM Build start
ESM dist/cli.js 22.83 KB
ESM ⚡️ Build success in 73ms
$ publint
Running publint v0.3.14 for @hono/cli...
Packing files with `bun pack`...
Linting...
All good!

$ bun dist/cli.js -g docs
Usage: hono [OPTIONS] COMMAND [ARGS]...

  CLI for Hono

Options:
  -g, --gen docs  Generate documentation.
  -h, --help      Show help.
  -v, --version   Show version.

Commands:
  docs      Display Hono documentation
  optimize  Build optimized Hono class
  request   Send request to Hono app using app.request()
  search    Search Hono documentation
  serve     Start server

Usage: hono docs [OPTIONS] [path]

  Display Hono documentation

Options:
  -g, --gen docs  Generate documentation.
  -h, --help      Show help.
  -v, --version   Show version.

Usage: hono optimize [OPTIONS] [entry]

  Build optimized Hono class

Options:
  -g, --gen docs           Generate documentation.
  -h, --help               Show help.
  -v, --version            Show version.
  -o, --outfile <outfile>  output file (default: "dist/index.js")
  -m, --minify             minify output file

Usage: hono request [OPTIONS] [file]

  Send request to Hono app using app.request()

Options:
  -g, --gen docs         Generate documentation.
  -h, --help             Show help.
  -v, --version          Show version.
  -P, --path <path>      Request path (default: "/")
  -X, --method <method>  HTTP method (default: "GET")
  -d, --data <data>      Request body data
  -H, --header <header>  Custom headers
  -w, --watch            Watch for changes and resend request (default: false)

Usage: hono search [OPTIONS] <query>

  Search Hono documentation (positionals required)

Options:
  -g, --gen docs        Generate documentation.
  -h, --help            Show help.
  -v, --version         Show version.
  -l, --limit <number>  Number of results to show (default: 5)
  -p, --pretty          Display results in human-readable format

Usage: hono serve [OPTIONS] [entry]

  Start server

Options:
  -g, --gen docs          Generate documentation.
  -h, --help              Show help.
  -v, --version           Show version.
  -p, --port <port>       port number
      --show-routes       show registered routes
      --use <middleware>  use middleware

$ bunx @hono/[email protected]
Usage: hono [options] [command]

CLI for Hono

Options:
  -v, --version               display version number
  -h, --help                  display help for command

Commands:
  docs [path]                 Display Hono documentation
  optimize [options] [entry]  Build optimized Hono class
  search [options] <query>    Search Hono documentation
  request [options] [file]    Send request to Hono app using app.request()
  serve [options] [entry]     Start server
  help [command]              display help for command

[kitaharata]

Hi @yusukebe @usualoma @ysknsid25
Given the scale of this framework migration, multiple reviewers would be helpful. Please take a look when you can.

[ysknsid25]

Hello @kitaharata, thank you for your working. I have a question.

What are the advantages of using tako over the risk of making breaking changes to existing code?

As far as I can think of,

• Faster than commanderjs
• Smaller than commanderjs
• Better quality than commanderjs (e.g, Higher test coverage)

I think you must proof these 3 points at least.

Moreover, yusukebe said,

we don't do this in the initial development phase of Hono CLI.

in #42 .

At this moment, I thought it would be best to first raise awareness of tako and get it closer to commander.js in terms of GitHub stars, npm downloads, etc.

[kitaharata]

Hello @ysknsid25, thank you for your comment and feedback.

First, regarding the question "What are the advantages of using tako over the risk of making breaking changes to existing code?", please refer to motivation.md for the background and reasoning.

Smaller than commanderjs:

According to Bundlephobia, commander.js and other similar libraries such as citty have significantly larger bundle sizes compared to tako.

• [email protected] — 39.5 kB (minified)
• [email protected] — 7.2 kB (minified) + its dependency [email protected] — 6.5kB (minified)
• @takojs/[email protected] — 7 kB (minified)

Faster than commanderjs:

To make a fair and objective comparison, we need to prepare proper benchmark tests for CLI frameworks, so please wait until those benchmarks are ready.

Better quality than commanderjs (e.g., higher test coverage):

This is difficult to compare directly because the testing approaches differ fundamentally.
Since we want to avoid relying on tools that provide cross-runtime testing for Node.js, Deno, and Bun, we use our own testing strategy.

This is Tako’s test script (there are still many examples/tests that haven’t been committed yet):

node scripts/test.js
deno -R scripts/test.js
bun scripts/test.js

At the very least, Hono CLI already runs tests, build checks, linting, and formatting checks, so the basic quality assurance workflow is in place.

[ryoppippi]

I think tako is quite new and unstable.
commanderjs is really mature and used in all hono packages.
and nowadays gunshi is much better in my opinion, it provides type-safe, rich features and smaller bundle size. it is also used in modern cli tools like ccusage

[usualoma]

Hi @kitaharata, thank you for your tremendous effort.

Commander is a well-established library, and functionally, this project (honojs/cli) currently has no issues with Commander.

Certainly, there are better libraries compared to Commander, but if we were to replace it (especially with one that hasn't been used yet), I believe there needs to be a sufficiently large corresponding benefit for both developers and users.

For example (and this is purely hypothetical—please don't rush into action based on this sentence), if replacing the library would enable “extremely easy support for shell completion,” that kind of major benefit would make it worth considering. Currently, I don't believe “smaller bundle size” or “faster speed” represent significant advantages for honojs/cli.

[kitaharata]

Hello everyone, thank you for the insightful discussion and the suggestions.

First of all, I would like to move this PR back to draft status.
Also, thank you for introducing Gunshi. I appreciate learning about new libraries and tools.

I have been thinking about the future direction for a while, and I still believe that Tako has strong potential, so I plan to continue developing it.
Recently, I succeeded in implementing validation using Standard Schema, and this further convinced me that the framework has significant capabilities.

Since automatic context generation for AI is one of Tako’s core features, I would also like to add functionality in the future that would make shell completion extremely easy to support (though this will require understanding many different shells).

Based on these recent developments, I intend to keep improving the Hono CLI and continue committing to this fork.
For that reason, I would like to keep this pull request open and move it back to a draft rather than closing it, and I hope that is acceptable to everyone.

Thank you again for your effort and for initiating this discussion.
I look forward to continuing to work together to make further improvements.