ð 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 ð§