This seems like a no brainer, but it is especially important when the code is to be shared with the open-source community. A lot can be said when referring to code quality, but there are two items that are worth discussing:
If possible, limit your library's number of dependencies. Adding too many dependencies can bloat your library, making it less desirable for others to use. Also, managing many dependencies can be very difficult and can create a lot of extra work. As a new version of a dependency becomes available or an old version is no longer supported, code changes are often required to stay up to date, or to keep your library from breaking. One extreme example of a dependency causing problems is when one developer broke thousands of projects by removing left-pad from npm. That story is a perfect example of a dependency that can easily be removed by just taking the time to rewrite the function yourself.
Universal Module Definition
output.library to the name of the library and
UMD in the webpack.config.js file, your library now supports multiple module definitions. Using UMD gives the end user the freedom to choose the tooling they want to use without having to adhere to a certain module format.
Once tools like linters and unit tests are added to the library, it would be nice to not have to run them manually for every commit. Creating a CI/CD pipeline will automate this process, and there are some great tools that you can use. My recommendation is Travis CI. It is extremely easy to set up and integrates well with GitHub. In fact, you can display a badge on the READ.ME that will indicate to the end user whether the current build is passing or failing. There are plenty of different processes that can be added to a CI/CD pipeline, but at a minimum there should be a process to run a code scan and a process to run the unit tests.
All of these "tips for publishing to npm" are not just for the developer(s) that maintain the library. It is all about demonstrating that the library is of high quality and creating a high level of trust with the end user. Another piece to this is creating detailed documentation. A user should be able to learn everything they need to know about the library through the documentation and only look at the source code if they are interested. I like to break up my documentation into these sections: Overview, Install, Quick Guide, Specs, and Examples.
A quick description of the library. What does it do? What problem does it solve? Why was it created?
Instructions for how to implement the library.
Instructions for how the developer can quickly start using the core functionality of the library. No need to present complex implementations.
Highly detailed descriptions of each component of the library.
Depending on the library, examples are not always needed, but it is great to provide a variety of implementations/use cases of the library. A demo of the library in action with a link to the source code can be really helpful.
npm login. Next, configure the package.json file. Below is a generic example:
npm publish. That's it! Your library is now on npm!