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

@formidable/dogs

v3.0.0

Published

Formidable Dogs

Downloads

14

Readme

dogs 🐕

npm version Actions Status Maintenance Status

Formidable Dogs

Install

$ npm install @formidable/dogs
$ yarn add @formidable/dogs

Contributing

This repository is configured using semantic-release which automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.

What does this mean for contributors? It means we need a merge commit that follows the conventional commit format. There are lots of ways to do semantic-release and commit vetting, but here's how we do it in this repo:

  1. Our target for semantic-release is a "Squash and merge" GitHub pull request merge. Our repository only allows this kind of merge. We aim to have the final commit meet the conventional commit format.
    • Note: This means that along the way to that final merge commit, it doesn't matter how you commit. We don't do pre-commit hooks, nor lint individual commits in a pull request. All we check is the final merge commit to make sure it's all good.
  2. This means that the thing you need to check is the pull request title which is what will be used in the squash and merge commit to trigger semantic release. We use semantic-pull-requests(NO LONGER MAINTAINED) to make sure that our PRs have a title meet the eventual format needed. And no worries about changes along the way! You just need to get the PR title in appropriate shape by the time you want to merge.

There are very precise rules over how git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. Also, the git commit messages are used to generate the AngularJS change log.

Anatomy of a pull request title

The semantic-pull-requests bot goes for the minimal semantic-release information to make doing versioning as easy as possible. For how we do it in this project, you just need to focus on the PR title (that must be preserved in the squash and merge commit).

The pull request title has a special format that should include a type, a scope and a subject:

<type>(<scope>): <subject>

The scope of the header is optional.

What type of commits trigger a release?

Type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test].

| Commit Types | Description | Version Impact | |--------------|-----------------------------------------------------|----------------| | chore | Changes to the build process | N/A | | docs | Changes to documentation | N/A | | feat | Changes that support a new feature | Patch | | fix | Changes that fix a bug | Minor | | perf | Changes that improve performance | Patch | | refactor | Changes that neither fixes a bug nor adds a feature | N/A | | style | Changes that do not affect the meaning of code | N/A | | test | Changes to the test process | N/A |

What about major version bumps?

Major version bumps are considered breaking changes for semantic-release and are triggered intentionally.

Breaking changes should start with a ! after the commit type. This changes a usual N/A version impact of something like refactor or fix to a breaking change with refactor! or fix!.

Examples

Any of the following PR titles should work for the appropriate release:

  • perf: removed pictures from published package: Patch
  • refactor(utils): change internal file utils: N/A. Add an ad-hoc scope.
  • refactor: change internal function: N/A
  • refactor!: remove dog .jpg files: Major

Maintenance Status

Active: Formidable is actively working on this project, and we expect to continue for work for the foreseeable future. Bug reports, feature requests and pull requests are welcome.