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.

Load fonts asynchronously & handle FOUT with my Gatsby plugin

Adrian Bece for PROTOTYP ・ Nov 3 '20

#react #gatsby #webdev #javascript

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.

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

Features

• 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 gatsby-omni-font-loader react-helmet

or

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

Configuration

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: ["https://fonts.gstatic.com"],

    /* Self-hosted fonts

…

View on GitHub

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.

Checklist for choosing an optimal npm package

Adrian Bece ・ Aug 22 '19

#npm #node #beginners #javascript

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

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.

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