Skip to main content

Command Palette

Search for a command to run...

What I Learned Building an Open Source CLI Tool for NestJS

Five things I discovered about Node.js, npm, ESM, and developer tooling that I never fully understood until I built create-nest-pro from scratch.

Updated
2 min read
What I Learned Building an Open Source CLI Tool for NestJS
P
Backend Software Engineer with a deep focus on server side architecture, security and scalable system engineering. I build with NestJS, Node.js, TypeScript and PostgreSQL and I write about the engineering decisions that separate systems that work from systems that last.

What I learned building create-nest-pro, an open source CLI tool that scaffolds a production ready NestJS project in seconds.

I spent time trying to make npm i and npx behave the same way and eventually hit a wall. npm deliberately blocks postinstall scripts from third party packages for security reasons. No package on the entire registry can bypass that. Understanding why npm made that decision taught me more about how the registry actually works than any documentation ever did.

I made the mistake of hardcoding package versions early on and quickly realized that every project scaffolded by the CLI would risk starting with outdated dependencies the moment any package released a newer version. So I built it to hit the npm registry at the exact moment you run the command and fetch the latest stable version of every single package in real time. Every project now always starts current without me ever touching the CLI code again.

I used both Commander.js and Inquirer.js in this project and realized they are solving two completely different problems. Commander.js handles how the CLI is structured and how it parses arguments. Inquirer.js handles the interactive questions the user answers. Before building this I would have said they do the same thing. They do not.

I ran into a breaking change with Inquirer.js that I did not see coming. Version 9 and above dropped CommonJS support entirely. That one discovery forced me to restructure the entire project to use ES modules. It was not optional and there was no workaround.

Building a tool that solves your own problem is the fastest way to understand a technology deeply. I have built production NestJS projects before. But building a tool that automates the entire setup forced me to understand every single configuration decision at a level I never had before.

npm: https://www.npmjs.com/package/create-nest-pro

GitHub: https://github.com/PeaceMelodi/create-nest-pro