<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Yash Hadade</title>
    <description>The latest articles on DEV Community by Yash Hadade (@yash_hadade_83abbb43fa06a).</description>
    <link>https://dev.to/yash_hadade_83abbb43fa06a</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F2463605%2Ff7fc56d7-b795-4f19-ab34-29b792aed5eb.png</url>
      <title>DEV Community: Yash Hadade</title>
      <link>https://dev.to/yash_hadade_83abbb43fa06a</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/yash_hadade_83abbb43fa06a"/>
    <language>en</language>
    <item>
      <title>I Built My First npm Package — A CLI for Scaffolding Modular Node.js Projects</title>
      <dc:creator>Yash Hadade</dc:creator>
      <pubDate>Fri, 29 May 2026 08:08:51 +0000</pubDate>
      <link>https://dev.to/yash_hadade_83abbb43fa06a/i-built-my-first-npm-package-a-cli-for-scaffolding-modular-nodejs-projects-180j</link>
      <guid>https://dev.to/yash_hadade_83abbb43fa06a/i-built-my-first-npm-package-a-cli-for-scaffolding-modular-nodejs-projects-180j</guid>
      <description>&lt;p&gt;The problem I kept running into&lt;br&gt;
Every time I started a new Node.js backend — whether it was a microservice at realX or a weekend project — I found myself doing the same ritual:&lt;/p&gt;

&lt;p&gt;Create the folder structure manually&lt;br&gt;
Copy-paste the same boilerplate files&lt;br&gt;
Wire up the same entry points, route structure, and config setup&lt;br&gt;
Then finally get to actually writing the thing I wanted to build&lt;/p&gt;

&lt;p&gt;It wasn't painful enough to complain about loudly, but it was persistent. And persistence is what eventually makes you do something about it.&lt;br&gt;
At work I own a scalable custodian backend — a system with a lot of moving parts that had to stay cleanly separated. Modules for blockchain workers, modules for custody logic, modules for event handling. Over time I developed a personal pattern for how I like to structure these things. A certain way of thinking about separation of concerns that felt natural and repeatable.&lt;br&gt;
That pattern is what became &lt;strong&gt;moduler-framework&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;What it is&lt;/strong&gt;&lt;br&gt;
&lt;strong&gt;moduler-framework&lt;/strong&gt; is a CLI tool that scaffolds modular Node.js project structures so you can skip the setup ceremony and get straight to writing logic.&lt;/p&gt;

&lt;p&gt;bash&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;npm install -g moduler-framework&lt;/strong&gt;&lt;br&gt;
Run the CLI and it generates a clean, opinionated folder structure built around isolated modules — each with its own scope, entry point, and wiring — so your codebase stays organized even as it grows.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The idea is simple: structure shouldn't be an afterthought. When you scaffold it right at the start, you get a codebase that's easier to reason about, easier to test, and much easier for another developer (or future you) to navigate.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why a CLI specifically&lt;/strong&gt;&lt;br&gt;
I thought about making it a runtime library — something you'd import. But the real value isn't in what happens at runtime, it's in what happens at the start of a project.&lt;/p&gt;

&lt;p&gt;A CLI felt more honest. You run it once, it gives you a foundation, and then it gets out of your way. There's no new dependency sitting in your node_modules forever. The generated code is yours.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Shipping it&lt;/strong&gt;&lt;br&gt;
Publishing to npm for the first time was both anti-climactic and quietly exciting. Anti-climactic because once you have a &lt;strong&gt;package.json&lt;/strong&gt; and an account, it's just one command. Exciting because you realize: this is public now. Anyone can install this.&lt;br&gt;
I had to think more carefully about:&lt;/p&gt;

&lt;p&gt;Naming — &lt;strong&gt;moduler-framework&lt;/strong&gt; is distinct enough to not clash, while still being searchable&lt;br&gt;
Versioning — committing to semver and Conventional Commits from day one to keep the changelog clean&lt;br&gt;
CI — setting up GitHub Actions with commitlint so version bumps stay disciplined&lt;/p&gt;

&lt;p&gt;The commitlint setup tripped me up more than I expected. Getting the CI to not fail on PR titles, fixing rebase history, understanding the difference between feat: and chore: in a way that actually maps to meaningful version bumps — all of that was a learning curve I didn't anticipate when I thought of this as "just a small tool."&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;What I'd tell myself before starting&lt;/strong&gt;&lt;br&gt;
Write the README before the code. Seriously. If you can't explain what your tool does in three sentences, you don't know what you're building yet.&lt;br&gt;
Keep the scope small and ship it. I had ideas for more features — interactive prompts, custom templates, a config file system. I cut all of it for v1. Ship the thing that solves the core problem. Everything else is v2.&lt;br&gt;
Conventional Commits pay off immediately. Once you have them, your git log becomes documentation. Don't skip this.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Try it out&lt;/strong&gt;&lt;br&gt;
bash&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;npm install -g moduler-framework&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;&lt;strong&gt;GitHub&lt;/strong&gt;: &lt;a href="https://github.com/yashhadade/moduler-framework" rel="noopener noreferrer"&gt;https://github.com/yashhadade/moduler-framework&lt;/a&gt;&lt;br&gt;
&lt;strong&gt;npm&lt;/strong&gt;: &lt;a href="https://www.npmjs.com/package/moduler-framework?activeTab=readme" rel="noopener noreferrer"&gt;https://www.npmjs.com/package/moduler-framework?activeTab=readme&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;If you've been doing the same folder setup ritual on every new project, maybe this saves you some time. And if you have feedback — issues, PRs, or even just telling me it doesn't work the way you expected — I'm genuinely interested.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;This is my first published npm package. Building it was part real utility, part curiosity about what shipping open-source actually involves. Turns out it involves a surprising amount of commitlint debugging.&lt;/em&gt;&lt;/p&gt;

</description>
      <category>node</category>
      <category>npm</category>
      <category>opensource</category>
      <category>javascript</category>
    </item>
  </channel>
</rss>
