Week 1: From Idea to Runnable CLI Framework

tianmai2019 — Tue, 21 Jul 2026 14:16:32 +0000

Week 1: From Idea to Runnable CLI Framework

Why I'm Building This Tool

If you've worked on frontend internationalization (i18n) before, you've probably encountered these problems:

Hardcoded Chinese text scattered throughout the project, not knowing where to start
Developers forgetting to put text in i18n config when building new features
Manual checks during code review being inefficient
Wanting to internationalize but not knowing the overall workload

So I decided to build a tool called i18n-pilot to address these issues.

Its first-stage goal isn't automatic translation – it's helping teams discover their i18n debt first.

This Week's Goal

The goal for the first week was simple: turn the idea into a state where development can continue.

I didn't pursue feature completeness or rush into writing core scanning logic.

Instead, I focused on solving several foundational issues first:

Project naming and positioning
Tech stack and project structure
CLI entry framework
Basic documentation
npm publishing workflow validation
Future development rhythm

What I Built This Week

1. Project Naming

The project name ended up being i18n-pilot.

The idea behind this name is: like a co-pilot, helping developers handle issues during the internationalization process.

Not taking over completely for developers, and not automatically translating everything from the beginning – but first providing prompts, checks, and assistance in the development workflow.

2. Tech Stack Selection

For the first version, I chose the most suitable combination for CLI tools:

TypeScript
Node.js
Commander (CLI framework)
Vitest (testing)
ESLint (code linting)

No heavy frameworks were introduced, and I didn't start with a web UI.

The most important thing at this stage is to quickly validate the scanning capability, and the CLI is the most direct entry point for developer tools.

3. CLI Framework Setup

I built the basic CLI skeleton with Commander.

Although the functionality is still simple, there's already an entry point that can be extended.

Future capabilities can be gradually added around commands:

i18n-pilot scan ./src
i18n-pilot scan ./src --format stylish
i18n-pilot scan ./src --rule jsx-text=off

Get the entry working first, and there will be room to grow later.

4. Bilingual README

I intentionally wrote both English and Chinese versions of the README.

The reason is that from day one, this project wants to balance domestic content recording and international open source distribution.

Chinese content is more suitable for recording real processes and easier to communicate with domestic developers.

The English README is the foundation for future entry into GitHub, npm, Product Hunt, dev.to, and other channels.

If you want to build tools for global developers, English materials aren't something to add at the end – they need to be prepared from day one.

5. npm Publishing Workflow Validation

I also did an npm publish dry-run in the first week.

npm publish --dry-run passed, but I encountered E403 when trying to publish for real.

The reason is likely that the npm account requires 2FA OTP, or I need to create a granular access token that allows publishing.

This issue isn't completely solved yet, but it's good to expose it early.

If I waited until all features were done only to find the publishing pipeline stuck, the cost would be higher.

6. Content Recording Preparation

This time, I don't want content to be something packaged at the end – I want it to grow with the product.

So the first week also prepared the first batch of recording materials, including why I'm building this, how the project started from 0, how to advance in side project time, etc.

Content isn't packaging – it's a retrospective.

It forces me to clarify why I did each step, how I did it, and what to do next.

Validation Results

At the end of the first week, the project already has:

A clear name and positioning
A runnable TypeScript CLI framework
Draft English and Chinese README
Logo draft
Pre-npm-publish validation
First batch of content materials

These things aren't complicated individually.

But together, they turn i18n-pilot from an idea into a project that can really move forward.

This is especially important for side projects.

Because side project time is fragmented, if there isn't a clear shell and rhythm, it's easy to not know where to continue every time you open the project.

Next Week's Plan

The focus of Week 2 will be on scanning capability.

Plans include:

Learn and integrate ts-morph
Support React / JSX / TSX file parsing
Extract Chinese strings and JSX text
Support directory scanning and exclude node_modules
Output scan statistics
Prepare for future rule system

The acceptance criterion is simple:

i18n-pilot scan ./src

Being able to actually scan Chinese text in the project.

Thoughts This Week

The biggest收获 this week is confirming a rhythm:

Don't wait for the product to be complete – first make the project visible, runnable, and continuable.

When working on projects before, I easily fell into a trap: not having the idea completely clear yet, rushing to write core features; features not stable yet, wanting to add more things.

The result was often a lot of code written, but the project not feeling like a truly publishable product.

This time I deliberately did the opposite.

First build the project shell, then gradually fill in the content.

This process also made me more certain: when building developer tools in the AI era, you don't necessarily have to build a big AI Agent from the beginning.

A more realistic path might be:

First find a pain point in a specific development workflow
Solve part of the problem with deterministic rules
Get reporting and configuration right
Then put AI in the right place to assist

The same applies to i18n-pilot.

It shouldn't promise "automatic completion of all internationalization" from the beginning.

A more reasonable first step is: first help teams see clearly where their i18n debt is.

Knowing where the problems are is what enables subsequent fixes, translations, PR generation, and continuous checks.

webdev #javascript #typescript #opensource #i18n #cli #buildinpublic

DEV Community: tianmai2019

Week 1: From Idea to Runnable CLI Framework

Week 1: From Idea to Runnable CLI Framework

Why I'm Building This Tool

This Week's Goal

What I Built This Week

1. Project Naming

2. Tech Stack Selection

3. CLI Framework Setup

4. Bilingual README

5. npm Publishing Workflow Validation

6. Content Recording Preparation

Validation Results

Next Week's Plan

Thoughts This Week

Tags

webdev #javascript #typescript #opensource #i18n #cli #buildinpublic