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

conventional-changelog-jshint

v4.0.0

Published

conventional-changelog jshint preset

Downloads

4,503,057

Readme

conventional-changelog-jshint

NPM version Node version Dependencies status Build status Coverage status

conventional-changelog jshint preset.

Issues with the convention itself should be reported on the JSHint issue tracker.

Install

# yarn
yarn add -D conventional-changelog-jshint
# pnpm
pnpm add -D conventional-changelog-jshint
# npm
npm i -D conventional-changelog-jshint

JSHint Convention

Overview

Commit messages are written in a simple format which clearly describes the purpose of a change.

The format in general should look like this:

[[TYPE]] <Short description>
<Blank line>

<Body / Detailed description>

<Footer>

Line lengths in commit messages are not strict, but good commit messages should have headers of no more than 60 characters, and bodies/footers wrapped at 100 columns. This renders nicely on Github's UI.

Header

The first line is the commit message header, which will indicate the type of change, and a general description of the change. This should fit within 60 characters, ideally. For instance:

[[FIX]] Ignore "nocomma" when parsing object literals

The title [[FIX]] indicates that the change is a bugfix, while the remainder clarifies what the change actually contains.

Several commit types are used by jshint:

  1. [[FIX]] --- Commit fixes a bug or regression
  2. [[FEAT]] --- Commit introduces new functionality
  3. [[DOCS]] --- Commit modifies documentation. Docs commits should only touch comments in source code, or scripts and assets which are used to generate the documentation.
  4. [[TEST]] --- Commit modifies tests or test infrastructure only
  5. [[CHORE]] --- Commit affects dev-ops, CI, or package dependencies

Body

<Body> is a detailed commit message explaining exactly what has changed, and a summary of the reason why. Lines in the body should be wrapped to 100 characters for best rendering.

For a historical example, see this example

Footer

<Footer> contains a description of any breaking changes, no matter how subtle, as well as a list of issues affected or fixed by this commit. Lines in the footer should be wrapped to 100 characters for best rendering.

For instance:

[[FEAT]] Enable `norecurs` option by default

Commit 124124a7f introduced an option which forbids recursion. We liked it so much, we've enabled
it by default.

BREAKING CHANGE:

This change will break the CI builds of many applications and frameworks.

In order to work around this issue, you will need to re-engineer your applications and frameworks
to avoid making recursive calls. Use Arrays as stacks rather than relying on the VM call stack.

Fixes #1000009
Closes #888888
Closes #77777

Based on https://github.com/jshint/jshint/blob/master/CONTRIBUTING.md#commit-message-guidelines