DEV Community

Cover image for Published my first NPM package - here's what I learned
Adrian Bece
Adrian Bece

Posted on

Published my first NPM package - here's what I learned

Two weeks ago I've published my Gatsby plugin as an NPM package. In short, I've noticed that Gatsby's font loading plugins were deprecated, outdated, and lacking some features, so I've developed a plugin that I wanted to actively maintain if it gains traction. You can read more about that story in my previous post.

In those two weeks, my package received almost 800 downloads. I've learned some lessons about publishing your own NPM packages and maintaining open source projects that I would like to share with you all in this post.

GitHub logo codeAdrian / gatsby-omni-font-loader

Font loader optimized for maximum performance. Removes render-blocking font resources and loads them asynchronusly. Handle FOUT & FOUC with font loading status watcher. Supports both local-hosted fonts and web fonts.

Omni font loader logo

Gatsby Omni Font Loader v2

  • Simple way to add webfonts or custom fonts to Gatsby project
  • Performant asynchronous font loading can be enabled
  • Font loading listener can be enabled
  • Flash Of Unstyled Text (FOUT) handling support


  • Supports web fonts & self-hosted fonts
  • Preloads the files & preconnects to the URL
  • Loads fonts asynchronously to avoid render blocking
  • Implemented with fast loading snippets
  • Loading status listener for avoiding FOUT
  • Small size & minimal footprint


npm install gatsby-omni-font-loader react-helmet


yarn add gatsby-omni-font-loader react-helmet


Add the following snippet to gatsby-config.js plugins array.

  /* Include plugin */
  resolve: "gatsby-omni-font-loader",
  /* Plugin options */
  options: {

    /* Font loading mode */
    mode: "async",

    /* Enable font loading listener to handle FOUT */
    enableListener: true,

    /* Preconnect URL-s. This example is for Google Fonts */
    preconnect: [""],

    /* Self-hosted fonts
Enter fullscreen mode Exit fullscreen mode

Open-source mindset

Have you developed something useful, reusable and that is well-made? Why not publish it as an NPM package?

Consider open-sourcing and publishing the NPM package that you wish you had available out of the box. Because there is a good chance there are quite a few more devs out there who might find the code useful.

However, if you decide on publishing the package, you should also keep in mind that you should also maintain it. If the package gains traction with the community, you can expect a few issues to open up, feature requests, and pull requests.

For now, let's keep the focus on publishing the package.

NPM best practices

I've outlined some NPM best practices in the article I wrote about a year ago.

What does it mean for your NPM package?

  • Make sure that dependency packages are kept up to date to avoid vulnerabilities
  • Address any issues that have been reported
  • Engage with people posting issues, feature requests, questions, etc.
  • Keep the package and the code optimized
  • Let the community know why your package stands above its competition

Alt Text

GitHub alerts you if your repo contains any vulnerabilities

Alt Text

It even creates automatic PRs for fixes

High-quality, informative docs

You need to provide informative docs so the community knows what your NPM package does, why they need it, and how do they use it.

Docs can be usually added with in the repo and they usually feature:

  • A short description of the package
  • How to install it
  • Simplest use-case
  • Available options for configurations
  • Examples and advance tips
  • FAQ or troubleshooting (to avoid repeated questions or issues unrelated to your NPM package)

Bug reports & contribution

As devs are downloading and using your npm package, it's unavoidable that they're either discover, have a feature request, send a pull request, or ask a question.

Maintaining a healthy user-base and engaging with the users is the best way to keep your NPM package going and used. No one likes to see an NPM package that has 10 or more issues open and no responses for weeks. That will discourage users from using your package.

What to do if the package doesn't get any traction?

At the time of writing this article, there are exactly 1,445,808 packages on NPM. So it's no surprise if your package doesn't get any traction or is not widely used. You can bet there are at least a dozen alternatives for whatever package you decide to develop, so having some stand-out feature is important.

But what to do if the package doesn't get any traction? You can either:

  • Spread the word - share it on social media, dev forums and channels, write articles, improve docs, ask colleagues to try it out...
  • Deprecate it
  • Transfer ownership to someone else who is willing to continue your work

If your package has dependencies, you don't want to leave it with vulnerabilities, so it's better to deprecate it if you decided not to continue maintaining it.


Publishing an NPM package is not only a set-and-forget kind of thing. Your dependencies might be outdated which leads to security issues, and users might ask questions, report bugs, offer pull requests, etc.

If you are publishing the package, make sure that you are ready to engage with your users from time to time, and to make sure that the dependencies are up to date.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Buy Me A Coffee

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Top comments (1)

bias profile image
Tobias Nickel

thanks for sharing your thoughts. I am also a publisher and maintainer for a bunch of modules.

Definitely a good documentation is key. 👍

A few modules that I published, I know are not useful, others I know are no longer needes, because there really is a better alternative. And I plan since 3 months to add a single page in my website where people can quickly see the state and up to dates opinion.

I basically have my own ORM on npm. It has the killer feature, that it can basically join across databases. even SQL to mongo to redis. but its typescript support is not good. I definetly need typescript version 4.1 to improve the type definitions. I used it in some personal projects,but never productive myself.

With tcacher I have a query batching solution that is superior to facebooks DataLoader. And I thought people rather use stuff from facebook thana random dude. that is what i thought,... I just never promoted the module.

This year, after more than 5 years, it is the first time that one of my modules is getting traction. first it have been 1500, when I realized finally people use one of my modules. It is my xml parser txml. The downloads started to rise, when I implemented support for processing streams via for await loop about 6 months before.

Now, I developed version 4 adding cleaner API, and some needed options for parsin. Boa, I was so nervous when I npm publish, I added more tests, use --dry-run to see the exact package content. I just can hope people like it.