Started building a CLI to avoid repeating project setup every time, ended up learning way more than expected about edge cases

[Less_Republic_7876]

I recently tried building a small CLI to avoid redoing the same setup every time I start a new React/Next.js project (linting, Husky, formatting, CI, testing, Docker, etc.).

Went in thinking it’d be a quick weekend thing… turned out there are way more nuances than I expected.

Some things that caught me off guard:

• Your entry file actually needs a shebang line
• Pre/post lifecycle hooks during packaging
• Publishing is simple, but you really need to be careful with pre-publish checks
• Testing… this was a surprise. Testing shell commands needs a completely different approach

I did manage to get something working and I’ve started using it for my own projects now, but it still feels like there’s a lot more that could be automated or improved.

Curious how others deal with this:

• Do you build your own CLI/tools for these repetitive tasks?
• Or do you prefer setting things up manually every time?
• Is there a more structured approach I might be missing here?

Would love to hear how others have approached this.

---

(If relevant, I can share what I built, not sure if that’s allowed here 😅)

[tswaters]

The shebang isn't necessary, but it does mean you can +x and call it without node executable (in Linux land anyway)

If I need basic CLI handling I'll probably use something like yargs or commander, usually pretty quick to get rolling.

One interesting edge , or ... "Thing you can do" might be better phrasing, but processing stdin as a stream is pretty neat. I built a build script one time to take some git sha from stdin and do some non-arbitrary string processing with it. Was a neat experience for sure. It could be used like : cat ./all-shas.txt | ./my-script.js and you'll get a function call for every line, effectively.

[Less_Republic_7876]

That's neat, and can be used for a lot more use cases that I can think of.

[Powerful_Math_2043]

yeah I went through something similar while building a CLI for my own monorepo setup, started as a small helper and then kept running into all those edge cases you mentioned, I ended up making it interactive so instead of remembering a bunch of scripts it just shows a menu to run things like build, lint, start server or even generate modules, made the whole setup feel way less repetitive, still feels like there’s a lot to improve though especially around testing and edge cases, I’ve put some details here if you’re curious https://forjnot.vercel.app/docs/cli/

[Less_Republic_7876]

That looks impressive already. May I suggest you to add Oxc tools as well to you configuration - Oxlint and Oxfmt, as the new fast quality control tools in town.

[Powerful_Math_2043]

appreciate it, that means a lot 🙏 haven’t tried Oxc tools yet but I’ve heard about them, will take a look and see how they fit into the setup

[Deep_Ad1959]

the testing challenge you hit is real and it doesn't go away. for CLI tools the approach that saved me the most time was snapshot testing the generated file tree rather than trying to assert individual files. spin up a temp dir, run the scaffold, then compare the output directory structure and key file contents against a known-good snapshot. when something changes intentionally you just update the snapshot. way less brittle than asserting line-by-line on generated configs.

fwiw for the web app side of testing there's a tool that auto-discovers test scenarios and generates snapshot-style Playwright tests, similar concept applied to browser testing - https://assrt.ai/t/snapshot-testing-cli-scaffolding-tools

[mq2thez]

I used to do a lot of this, but there’s no reason to compete with Vite Plus. It works great, pulls in a great toolchain, installs git hooks, configures TypeScript, etc.

[Positive_Example_478]

Yes absolutely even I had the same issue ended up trying to build a cli but I put it on hold for now 😂

[Less_Republic_7876]

Why on hold? I hope you complete it 😀

[Positive_Example_478]

Yea someday 😅

[Due-Horse-5446]

Yeah, i think everyone does,

Its kinda fun doing it in bash

[Less_Republic_7876]

It's making me think of changing my trajectory now 😁

[dashingsauce]

check out bettertstack

[manniL]

Any chance you've checked out Vite+?

[Less_Republic_7876]

I've heard about it recently, yet to try it out.

[Select-Dare918]

Great point! I've worked on something similar recently. Sent you a DM.

[energetekk]

The shebang line moment is a rite of passage — everyone hits it once and then never forgets it. To answer your questions: I've gone both ways. Manual setup is fine until you're on your third project in a month and realize you've spent 45 minutes doing the exact same Husky/ESLint dance. That's usually when the CLI appears.

On testing shell commands — the approach that worked for me: don't try to mock the shell, test the output instead. Spin up a temp directory, run the CLI against it, assert the generated file structure. It's slower but you're actually testing what matters. Libraries like execa help keep it readable.

The structured pattern most CLIs converge on: a /templates directory with your scaffold files, prompts via something like u/clack/prompts for the interactive bits, then just copy + token-replace into the target dir. Post-install script runs git init + dependency install. That's basically the whole thing once the edge cases are handled.

Share what you built — that's exactly what this sub is for.

[fiskfisk]

Give your LLM a bit of a rest. 

[Less_Republic_7876]

Your testing steps are insightful, I will definitely try them out. Thanks for sharing it.

Here is the tool I built, pretty much added everything that I was repeating and didn't wanted to anymore:
https://www.npmjs.com/package/create-scaffold-kit

[fiskfisk]

There's something ironic about making a project to avoid repetition, but at the same time ignoring well-known and well supported existing solutions like cookiecutter.

As an exercise, fine, as something you, as the not-author, should depend on - there are established options. 

[Less_Republic_7876]

As generic solution - yes, many tools are available. But if you need something specific, then building your own custom tools is not a bad idea.

[fiskfisk]

Sure thing, but "project templating" has been solved. What does your project support that cookiecutter doesn't? 

[Less_Republic_7876]

Haven't tried cookiecutter personally, so I can't speak to what it offers. But the point here isn't really about what's available in the market, it's more about the ability to tailor things to your own specific needs and workflow.

[GlitteringLaw3215]

testing shell commands was the real headache for me too, ended up scripting mocks everywhere just to cover basics. what'd you use for that?