š TL;DR
I'm kicking off a new NodeJS starter template and crowdsourcing the best tips, packages, and āwhy didnāt anyone tell me?!ā stories from the community. Drop your go-to NPM tools, must-have configs, or even horror stories in the comments. Bonus points for anything that saves headaches or sparks āahaā moments!
šļø Why Iām Building This
Itās hack time again and, okay, this project isnāt exactly going to win any beauty contests - but itās overdue. Iāve been wanting a solid, ESM NodeJS repo template with all my favorite dev goodies baked in and ready to go: Husky, Prettier, ESLint, Vitest, and more.
āØš§āš» If we havenāt met: I donāt do anything halfway. Iām either all-in, or it sits in my āwhen I have time (that never happens)ā pile. So I decided to go all out and create a no-nonsense, highly functional, plug-and-play template - one I wish Iād had at the start of half my projects.
š§ The Plan (So Far)
Hereās what Iām thinking for v1:
- Project structure:
/src,/tests,/docs - Husky hooks:
- Enforce Jira keys in branch names
- Warn about big commits
- Make sure all tests pass (debating how to handle skip...)
- 85%+ unit test coverage
- Prettier: Auto-format staged files
- JS, JSON, Markdownāwhat else should I include?
- ESLint (strict):
- Airbnb + maybe Unicorn
- Auto-fix
- No warnings allowed
- My custom rules:
- Ban try/catch in test files
- Block inline ESLint disables
- CSpell:
- Preloaded dictionaries + project-specific terms
- Conventional commits / Semver / CHANGELOGS:
- Iām a noob here - I know commitlint, but would love advice!
- Vitest:
- Unit + integration test scaffolding
- Docs:
- Simple, clean, GitHub-flavored Markdown
- My goal is plug-and-play scaffold with an ELI5 "why" baked in
- GitHub Copilot:
- Starter instructions included
š¤ If the last one surprises you, see my last few posts!
š¦ For the Backend Ducks (and Frontend Folks Too!)
Iām a backend duck-typist at heart, so the first release will be vanilla JS (think REST/GraphQL/MVC logic), not frontend. But if youāve got killer ideas for TypeScript or React setups, hit me up anyway! Iāll collect your suggestions for a āfuture featuresā list.
š§š» Share your wisdom below!
Stories, links, random ādonāt do thisā advice - all welcome.
Letās make NodeJS onboarding boringly reliable... and maybe a little less boring. š«¶
š”ļø RAI Disclaimer
Everything I share here is my own perspectiveācreated with the help of AI tools (GitHub Copilot, ChatGPT, and their friends), but always with a human in the loop. I do my best to catch accidental bias and fact-check, but if you ever spot something odd, let me know! AI isnāt perfect, and neither am I.
TL; DR: AI helped, but you can blame me for the chaos! š«
Top comments (6)
I'll offer this story.
As a senior architect, I get to pick the tools, frameworks, and technologies for the projects I'm involved in. I've written several front-ends in AngularJS, Angular, Knockout, jQuery, and plain JavaScript. I'd always want to build something with React given all the hype around it. So I went looking for how to start a react project.
As any react developer knows, there are dozens of starter projects and starter templates. All of them have a goal of trying to set up a developer to begin writing code as fast as possible. I've used the vite starter template, BulletProof react, create-react-app, etc. You name it, I probably ran the
npx runorgit cloneto get started.I think the biggest thing I hated about the whole experience was that all of these starter templates would include a plethora of libraries I'd never used before and offered no explanation of why the library was included. Axios, zod, zustand, react-query; these were included as part of my "intro" to react and I'd never touched any of them. And with names that descriptive, I spent more time researching the package and its alternatives than I did writing code.
All that to say this. If you're creating a boilerplate, the most important piece is going to be the documentation.
There's more to the journey, but this is already long-winded enough.
I'd suggest adding plop or yeoman to your boilerplate. You can write your own templates for components, unit tests, etc. When creating a new piece or feature to add to your project involves creating more than one file, or a file with a specific structure, these tools are a must have. A quick
yo componentin a front-end framework will save you time and energy.Thatās a great perspectiveāthanks for sharing!
Honestly, I hadnāt really thought much about the code itself yet, but youāre spot on about the packages. Up until a few months ago, I hadnāt touched frontend since college (which feels like a lifetime ago!). Having an intern this summer was actually perfect: gave me a chance to guide him and gave me cover while I figured out what half the dependencies were doing. Definitely not the most glamorous stage of a project!
You reminded me of something funny: Iāve started plenty of projects from scratch, but can count on one hand how many times Iāve used a starter. The idea of trying one didnāt even cross my mind for this š¤Æ š¤£ Guess I prefer to see where my own ideas take me first. Maybe Iāll regret that, but itās part of the fun.
Really appreciate all your insights here! Itās a solid reminder of what to watch out for, and Iāve added all your points to my ever growing checklist. Please, if you think of anything else, send more my way!
this is extremely impressive, seriously. every time i've hacked together my own setup, something always trips me up months later and i end up regretting skipping some early config. you ever find there's a tradeoff between enforcing strict rules and onboarding new folks fast enough
Thanks! š This is one of those bits Iāve built a hundred times, always tweaking it mid-stream, so itās been on my ājust ship it alreadyā list for a while. That and it's the perfect opportunity to get my hands on some new toys that I've been trying to find an excuse to use anyway.
On strict rules: I used to be skeptical, but honestly, once you find something that works it makes onboarding smoother for everyone (new folks and seasoned devs alike). Have you ever tried this approach (I mean formatting first, and then styles after)? It took me a bit to buy in, but now Iād never go back.
Most of itās automated, so during onboarding, I just give the āSorry, new formatter. Turn auto-format off if you have toā speech. For new devs, the rules are actually a secret weapon: they push you to spot and fix problems youād otherwise miss. Itās usually a low-impact, safe space to practice debugging (time-boxed, of course).
āØ Fun twist: I actually discourage using AI for this, at least for junior devs.
Experienced devs? Fire away - knock it out in 30 seconds or less. But strict rules are worth a few grumbles on the team. Iāll take that over chaos any day!
šāāļø If anyone wants the epic-saga version, Iāll happily write a follow-up with all the gory details and what finally convinced me to make the switch.
github.com/sebs/superminimal/
node types, typescript, tsx
Awesome - thank you! I'll check it out š§