How I Published My First npm Packages

Sandeep Prajapati — Fri, 31 Jul 2026 10:10:44 +0000

How I Published My First npm Packages

If you've ever copy-pasted the same capitalize() or isPrime() function into three different projects, this post is for you.

I recently published my first two npm packages — sp-number-kit and sp-string-kit — and I want to walk through the actual journey: why I built them, what tripped me up, and the exact steps to publish, test, and link your own package to GitHub.

The Problem: Same Logic, Written Differently, Every Time

Every developer has written an "is this number even?" check or a "convert this to camelCase" function at some point. The problem is:

The same operation gets rewritten across projects, teams, and even by the same developer six months apart.
Different implementations of the "same" logic aren't always accurate, which can quietly introduce bugs or performance issues down the line.
We could build project-specific utility files, but they stay locked inside that one project instead of being reusable.

That's the gap I wanted to close. So I built two small, focused utility kits:

sp-number-kit — even/odd checks, prime checks, factorial, GCD, LCM, clamp, average, and more.
sp-string-kit — capitalize, palindrome check, camelCase/snakeCase/kebabCase conversion, slugify, and more.

Nothing fancy. Just small, tested, reusable functions that I (and hopefully others) can npm install into any project instead of rewriting from scratch.

The Trickiest Parts

Publishing a package sounds intimidating before you've done it once. Here's what actually gave me pause:

1. npm authentication with 2FA
npm now enforces two-factor authentication (2FA) for publishing, and this is something to handle carefully. If you're not prepared for the prompt, npm publish can fail or hang waiting on a one-time code you didn't expect.

2. Testing locally before publishing
This turned out to be the most important step in the whole process. Before every publish, I made sure to run every function locally against expected outputs — even/odd, prime, factorial, gcd, lcm, and all the string transforms. It's easy to assume a function "obviously works" and skip this, but that's exactly how bugs slip into a published package that other people now depend on.

3. Writing a clean, accurate README
A utility package lives or dies by its README. If someone can't tell what a function does and what it returns within 10 seconds, they'll bounce. I had to be deliberate about keeping mine clean, accurate, and complete for every exported function.

The "Aha" Moments

A few things surprised me in a good way (and one in a "wish I knew earlier" way):

Publishing itself is genuinely simple. Once your package.json is set up correctly, it's really just npm publish. All the complexity is in the prep, not the publish command itself.
Version bumps are non-negotiable. Every single time you make a change, you must bump the version before publishing again — npm won't let you republish the same version number, and skipping this is a rookie mistake I made early on.
npm login needs a second look now. Because of 2FA, logging in isn't just "type your password and go" anymore — keep this in mind so it doesn't block you mid-release.
Linking to GitHub is almost too easy. You just reference your repository in package.json, and npm automatically shows the GitHub link on your package page. No extra CI/CD or manual linking required.

Step-by-Step: Publish, Test, and Link to GitHub

Here's the exact flow, from an empty folder to a live, GitHub-linked npm package — visually first, then step-by-step below.

Step 1: Check if your package name is available

Before writing a single line of code, check whether your desired name is already taken on npm:

npm view sp-number-kit

If it returns package details (version, description, etc.), the name is already taken — pick another one.
If it returns a 404 / "not found" error, the name is free and you're good to go.

Skipping this check is a common rookie mistake — you don't want to build and test everything only to find out at publish time that the name is unavailable.

Step 2: Set up your project

mkdir sp-number-kit
cd sp-number-kit
npm init -y

Step 3: Write your functions and export them

Structure your code so everything is exported from a single entry point (e.g. index.js), so users can do:

const { isPrime, factorial } = require('sp-number-kit');

Step 4: Test locally before touching npm

This is the step people skip and regret. Options:

Use npm link to symlink your package into a test project locally and try every function as a real consumer would.
Or add a simple test script (Jest, Vitest, or even plain Node scripts) that checks expected outputs for each function.

Don't publish until every function behaves exactly as documented.

Step 5: Write a clean README

Cover: what the package does, installation command, and a usage example for every exported function. Treat it like the first (and maybe only) thing a stranger will read before deciding to trust your package.

Step 6: Link your package to GitHub

In your package.json, add:

"repository": {
  "type": "git",
  "url": "https://github.com/your-username/sp-number-kit.git"
},
"bugs": {
  "url": "https://github.com/your-username/sp-number-kit/issues"
},
"homepage": "https://github.com/your-username/sp-number-kit#readme"

That's genuinely all it takes — npm automatically shows this link on your package's npm page.

Step 7: Log in to npm (watch out for 2FA)

npm login

If you have 2FA enabled on your npm account, be ready to enter your one-time code when prompted.

Step 8: Publish

npm publish

If it's your first time publishing a scoped or public package, you may need:

npm publish --access public

Step 9: Test after publishing (don't skip this!)

Once it's live, install it fresh in a separate test folder — just like a real user would:

mkdir test-consumer
cd test-consumer
npm init -y
npm install sp-number-kit

Then write a tiny script that imports and calls each function, confirming the published version behaves exactly like your local one.

Step 10: Bump the version for every future change

Whenever you fix a bug or add a feature:

npm version patch   # or minor / major, depending on the change
npm publish

npm will reject a publish if the version number hasn't changed — this is your safety net against accidentally overwriting a live version.

Wrapping Up

Publishing sp-number-kit and sp-string-kit taught me that the actual npm publish command is the easy part — the real work is in careful local testing, a genuinely useful README, and staying on top of versioning and 2FA. If you've been putting off publishing your own utility functions, this is your sign to just try it.

Check them out and let me know what you think:

If you publish your own package after reading this, drop a comment — I'd love to see it!

DEV Community: Sandeep Prajapati

How I Published My First npm Packages

How I Published My First npm Packages

The Problem: Same Logic, Written Differently, Every Time

The Trickiest Parts

The "Aha" Moments

Step-by-Step: Publish, Test, and Link to GitHub

Step 1: Check if your package name is available

Step 2: Set up your project

Step 3: Write your functions and export them

Step 4: Test locally before touching npm

Step 5: Write a clean README

Step 6: Link your package to GitHub

Step 7: Log in to npm (watch out for 2FA)

Step 8: Publish

Step 9: Test after publishing (don't skip this!)

Step 10: Bump the version for every future change

Wrapping Up