npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@logdna/commitlint-config

v2.0.0

Published

Commitlint configuration to enforce commit message best practices

Downloads

5

Readme

commitlint-config

Commitlint Configuration to enforce commit message best practices on public repositories

Installation

$ npm install commitlint @logdna/commitlint-config

Usage

To enable commit linting, you need two things in package.json

  1. npm script exposing commitlint
  2. commitlint configuration that extends the logdna base configuration Adding a script to expose commitlint in the package.json scripts. Below is an example of linting all commits on the active branch that have not been merged into main
"commitlint": {
  "extends": "@logdna/commitlint-config"
},
"scripts": {
  "commitlint": "commitlint --from=origin/main --to=HEAD",
  "pretest": "npm run commitlint"
}

Command Line Tool

This package may additionally be installed globally as a command lint tool (commitlint-mezmo)

$ npm install -g @logdna/commitlint-config
$ commitlint-mezmo <options>

or executed immediately with npx

$ npx @logdna/commitlint-config -f origin/master

OPTIONS

  -h, --help                 show help and usage
  -v, --version              show version
  -f, --from [origin/main]   the git ref where linting should begin
  -t, --to [HEAD]            the git ref where linting should end
  -p, --pwd <path>           set the root directory
  --config <path>            path to an alternate commitlint config module

Commit Format

Commit message should follow the Conventional Commit Standard, and be be written in imperative form.

  • A proper title - This summarizes what was done in the commit
  • A descriptive commit body. This says WHY the change was made in addition to what it was. A blank line should start and end the commit body.
  • BREAKING CHANGE: (case-sensitive) in the footer to indicate a major change
  • Break lines of text at 72 columns. This is for readability.
  • Fixes: tag at the bottom of the body to associate the changes with an open issue

Example:

fix(test): Add tests for component XYZ

The component for XYZ was missing a test which resulted in a
production bug.  There was an unchecked reference that caused
a `TypeError`.  This change adds the reference fix and a
corresponding test.

Fixes: #35

Valid Types

The first bit of the commit message is the type, which has a finite list of acceptable values:

  • build
  • ci
  • chore
  • doc
  • feat
  • fix
  • lib
  • perf
  • refactor
  • style
  • test

The scope is required, but is not validated.

Example:

pkg(initial): The first commit of this package

This is the initial commit for the project scaffolding and code.

Fixes: #1

Ignored Commits

There are certain commits formats that will be ingored by the linter. These tend to be commits that are generated by known tools we use or commits that we have determined should not be linted in the sake of developer performance.

  • Commits generated by depenency managers (dependabot / renovate)
  • Commits generated by secerity tools (snyk)
  • Commits generated by versioning and release tools (versioner, semantic-release)
  • Commits that are titled doc(wiki)
  • Commits that are titled wip:
  • Dependency commits, chore(deps):, that are non-breaking

Examples:

Documentation commit only:

doc(wiki): Adding additional clarifying documentation

Adding some additional documentation that should make using this
more obvious to the casual contributor

Commits denoting something is still a work in progress

wip: this will be ignored

A minor or patch dependency update

chore(deps): Bump [email protected]

Authors