Steps to check when starting, working and publishing a module to NPM
You can add the included CHECKLIST.md into your project,
or copy it into your README.md; then check items off as you go.
Use one of the two badges to let everyone know your module is solid.
run linting and unit tests on each commit locally. pre-git, ghooks and use ban-sensitive-files to avoid committing sensative files (like private keys).
production and dev dependencies being out of date david-dm
semantic release badge
code quality badges
insecure code or dependencies
check module published size and white list only necessary files, tutorial
setup semantic-release to automate publishing
and avoid breaking semver. This is important,
but is currently broken in too many projects. Even this checklist is using semver!
avoid surprizes by using exact versions of the top level dependencies.
Use save-exact NPM setting and exact-semver to enforce it.
setup a script to reliably update out of date dependencies using next-update
setup automatic pull requests when newer versions of dependencies appear greenkeeper.io
if writing a CLI tool, add a way to check if it is out of date and should be upgraded;
update-notifier
scan dependencies and code for known security vulnerabilities. snyk, NodeSecurity
write simple installation commands for your module
write "quick intro" example showing the main feature of your module
add CONTRIBUTING.md file with clear guidelines how others can add new features or fix bugs
in your module. Atom editor and lodash have excellent examples to follow.
When GitHub finds a CONTRIBUTING.md file it shows a message to anyone opening an issue.
generate documentation automatically. xplain is my own tool for JS to HTML/Markdown
generation
place most of the public API documentation in README file for simple retrieval.
This allows other developers to find relevant sections right from the command line manpm
or by looking up npm home package-name
use a library to output the correct plural forms of words in the user messages pluralize
If you include the separate checklist file, you can automatically insert / update it inside the README.
Setup the markdown update as a step in your build process using update-markdown.
Contributing
Everyone is welcome to submit pull requests with new content.
I just ask to check before submitting a new content that:
it is not covered by an item that already is in the list.
if there is an open issue,
please reference it in your commit message.
You can even check the list of issues from command line before committing npm run issues.
has links to an explanation why it is a good idea and tools that help accomplish it.
Make sure to run npm run build once to update the checklist inside README.md