DEV Community

Jan Küster
Jan Küster

Posted on

Yet another NPM package template

There are already so many NPM package templates out there but I still had to do my own. This is basically due to a very subjective preference of tools.

We all know that the JavaScript world has so many different tools for similar or same purposes and once you are good with one you may not switch so easy to another unless there is a strong reason for that (new project with new tech decisions; package is abandonware; bad decisions by owners etc.).

In this article I'd like to present you my NPM package template that is designed to let you start coding right away. No complex setup, co further configs:

It also comes with a bunch of scripts included. Once you start writing you have all the tools you need to lint, test and build:

  • lint - run the linter
  • lint:fix - run the linter and try to fix simple issues
  • lint:test - run the linter and then the tests
  • test - run the tests once
  • test:coverage - run the tests once and create a coverage report
  • test:watch - run the tests in watch mode
  • docs - build the documentation as HTML and Markdown version
  • build - transpile the code
  • build:min - minify the code
  • build:full - transpile and minify
  • build:ci - lint, test and then build full

Techs included

The following section may be subject of debate as there are some less popular choices made and I will go into them. The template basically comes with no dependencies (only dev-dependencies) and the following toolset:

Why Mocha and not Jest?

I chose Mocha before Jest mainly because I still have a good out-of-the-box knowledge with Chai (asserter) and Sinon (stubbing/spying). Also I am involved in two mid-scale projects that both use Mocha/Chai/Sinon since quite a time and may not switch to Jest soon. Maybe you have a similar background and this template might be just the right one :-)

Why standard and not prettier?

I am using standard because it's ruleset is similar to what I perceive as good readable code plus it does not need any configuration. I also like the idea that the linter can fix some issues but does not alter all your codebase. Over time I got really comfortable with writing well-formatted and readable code by default and it was not that hard because the less important issues were still be fixed using the --fix option.

Why Travis-CI and GitHub actions

I included both because most of the matured projects I am involved with are heavily using Travis but I also included GitHub workflows step-by-step in my newer projects and since both are not interfering I can see only benefits for doing it.

The GitHub workflow is also split in three jobs here:

  • lint
  • test
  • check coverage

where each step requires the former to be passed. This is great because on any pull request you can clearly see which of these three caused the testsuite to fail and you need less time to evaluate the root cause.


Many of my recent NPM packages are built on-top of this template and it made it so much easier for me to start bringing ideas directly to code.
I felt it to be a great experience and I wanted to share this with you.
I'd love to get any feedback on this to see how you experienced it and where this can be improved.

Top comments (0)