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

@m-scott-lassiter/semantic-release-github-npm-config

v2.0.1

Published

A common, shareable configuration for publishing on Github and NPM

Downloads

12

Vulnerabilities

Powered byPowered by Snyk
  • 0High
  • 0Medium
  • 0Low

Links

Git

Maintainers

m-scott-lassiterm-scott-lassiter

Keywords

semantic-releasesemantic-release-configgithubgitreleasechangelognpm

Readme

@m-scott-lassiter/semantic-release-github-npm-config

NPM Version NPM Package Size License

Commitizen friendly semantic-release: angular

Build Dependency status Vulnerabilities Open Issues

Maintained contributions welcome

Purpose

This is a shareable configuration for semantic-release and documents a standard commit message and continuous release practice.

It uses the following plugins:

Install

Follow these detailed installation insructions.

Using in Projects

This specification is inspired by and supersedes the Angular Commit Message. Feel free to copy and modify this section in your own project, or link back here as a common resource.

Commits

If possible, make atomic commits, which means:

  • a commit should contain exactly one self-contained functional change
  • a functional change should be contained in exactly one commit
  • a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, feature with documentation etc...)

A complex feature can be broken down into multiple commits as long as each one maintains a consistent state and consists of a self-contained change.

This project uses very precise rules over how Git commit messages must be formatted. This leads to easier to read commit history.

Each commit message consists of a header, a body, and a footer.

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and must conform to the Commit Message Header format.

The body is mandatory for all commits except for those of type "docs". When the body is present it must be at least 20 characters long and must conform to the Commit Message Body format.

The footer is optional unless resolving issues. The Commit Message Footer format describes what the footer is used for and the structure it must have.

Commit Header Format

The header contains succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize first letter
  • no dot (.) at the end
  • if the commit is of type revert, include reverts commit <hash>, where the hash is the SHA of the commit being reverted
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: <custom>|api|contributing|license|readme|security
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|revert|test

Types

Required. Must be one of the following:

  • api: Non-functional changes to code API documentation that help other developers understand how to use a tool or feature (i.e. intellisense)
  • build: Changes that affect the build system configuration, package scripts, or dev dependencies (i.e. adds/remove/modify/update)
  • ci: Changes to CI configuration files and scripts (e.g. release configs, YAML scripts)
  • docs: Documentation only changes
  • feat: Adds or enhances a new matcher
  • fix: Fixes a bug in an existing feature. Also used for non-dev dependency updates.
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • revert: Revert to a commit
  • test: Add missing tests or correct existing tests

Scopes

Optional. If used, must be one of the following supported scopes:

  • <custom>: Used for extending these settings with your own project's requirements
  • contributing: Contributions to this guidance or the Code of Conduct
  • license: Changes to terms or copyright status within the license.
    • Any change in license type MUST include a BREAKING CHANGE
  • readme: Contributions to the main README.md
  • security: Changes that address code related security issues or security policies

Commit Body Format

Provide a plain text description of why you made this change. This is the place for you to explain your thought process, developer to developer. If helpful, include a comparison of the previous behavior with the new behavior to illustrate the change's impact.

If there are breaking changes, start the body with BREAKING CHANGE: <breaking change summary>.

Commit Footer Format

The footer identifies which issues this commit fixes. If none, leave it blank. Otherwise, use the format Resolves #<issue number>. If more than one issue is resolved, separate them with a comma.

Versioning Triggers

This project uses Semantic Versioning and updates automatically based on specific types used in the commit messages.

Pushes to the main branch causes semantic-release to check all commits since the last version for any triggers that would cause a new version. This project extends the defaults:

  • Patch
    • fix
    • perf
    • api
  • Version
    • feat
  • Major
    • BREAKING CHANGE

Extensions from the semantic-release default:

  • api triggers a patch. Only use this type for non-functional changes to code API documentation that help other developers understand how to use the code.
    • Appropriate use: changing JSDoc comments to make Intellisense more useful for other developers
    • Inappropriate use: Adding a new function (use feat), removing an optional parameter (use BREAKING CHANGE)

This keeps API documentation for the end user as a first-class citizen without patching for any and all changes to the README or other supporting docs.

Example Commit Messages

Minor Version Change:

feat(index): add function `foo`

This function adds the key functionality to the project.

Resolves: #1

Patch Version Change:

fix(index): add function `foo`

This function adds the key functionality to the project.

Resolves: #2

Major Version Change:

feat(index): add function `foobar`

BREAKING CHANGE: This function does some new useful things. Due to refactoring in the `foo` function, it no longer

Resolves: #3

No Change:

docs(readme): update readme to document new changes to `foo`
refactor: change `foo` implementation to faster xyz algorithm

Patch Version Change:

api: update the JSDoc comments in the `foo` function for parameter clarity

License and Development

This configuration and all other files in this repository are distributed as free and open-source software under the MIT License, © 2022.

Contributions and bug reports welcome.

Leave a :star2: if you find this project useful!

Contact

Maintained by M. Scott Lassiter.

GitHub Badge Profile Twitter Badge Profile LinkedIn Badge Profile Stackoverflow Badge Profile