Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
November 16, 2020 06:47 am GMT

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.

Gatsby Omni Font Loader

Performant asynchronous font loading plugin for Gatsby.

  • 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

Install

npm install --save-dev gatsby-omni-font-loader

or

yarn add --dev gatsby-omni-font-loader

Configuration

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

{  /* Include plugin */  resolve: "gatsby-omni-font-loader",  /* Plugin options */  options: {    /* Enable font loading listener to handle FOUT */    enableListener: true,    /* Preconnect URL-s. This example is for Google Fonts */    preconnect: ["https://fonts.gstatic.com"],    /* Font listener interval (in ms). Default is 300ms. Recommended: >=300ms */    interval: 300,    /* Font listener timeout value (in ms). Default is 30s (30000ms). Listener will no longer check for loaded fonts after timeout, 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 README.md 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.

Conclusion

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.


Original Link: https://dev.to/adrianbdesigns/published-my-first-npm-package-here-s-what-i-learned-49j6

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To