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.
Top comments (0)