freecodecamp / cz-freecodecamp

Commitizen adapter for freeCodeCamp.

cz-freecodecamp

Status:

A plugin for commitizen built for freeCodeCamp

Table of Contents

• Introduction
• Installation
• Usage

Introduction

This Commitizen adapter helps standardize commit messages for freeCodeCamp so being asked to fix incorrectly formatted commit messages will be less of a problem.

Installation

Install as a global adapter for freeCodeCamp repos

# Install the commitizen cli globally
npm install --global commitizen

# Install the freeCodeCamp commitizen adapter globally
npm install --global cz-freecodecamp

# Save the adapter into global config
echo '{ "path": "cz-freecodecamp" }' > ~/.czrc

Usage

Usage on freeCodeCamp's repos

... # Make changes

# Stage changes
git add changed-file

# This adapter is bundled in the freeCodeCamp main repo as a dependancy.
# Either use the inbuilt script
npm run commit

# Or alternatively on any of freeCodeCamp's repos including the main repo,
# use git cz instead of git commit
git cz

Note: Please check the contributing guidelines on the main repo for more on usage.

cz-freecodecamp's Issues

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

should allow some numbers in subject

https://github.com/freeCodeCamp/cz-freecodecamp/blob/master/index.js#L1
This currently in is catching all numbers. For example:
add es6 globals is rejected

cc @erictleung @raisedadead

Add example to clarify instructions

The instruction "Write a short, imperative tense description of your change" can be unclear for non-native English speakers. This could be clarified by adding an example. "E.g. Fix formatting for challenge X".

Also, a question: This is a CLI right? Then it would break my git editor setup?

Accommodate questions to close issues from commit message

## Issue

Right now, the commit title allows for anything e.g. issue numbers. They shouldn't be allowed. Additionally, if an issue number is referenced in the questions, you have to put `Closes #xxx` explicitly. Otherwise, it will just append whatever you input

## To Do

- [x] Prevent issue numbers to be in the commit title (regex for `/#\d+/`) (https://github.com/freeCodeCamp/cz-freecodecamp/pull/13)
- [ ] Fix the appending of issue numbers so that it has the keyword `Closes` before all issue numbers (https://github.com/freeCodeCamp/cz-freecodecamp/pull/14)
- [ ] Allow comma separated list of issues (https://github.com/freeCodeCamp/cz-freecodecamp/pull/14)

Add adapter locally on the repo and update instructions

Use seven rules of good commit messages?

If we plan on using this as a standard way of making commit messages on the main repo, maybe we should consider using these guidelines "The seven rules of a great Git commit message".

Here they are:

• Separate subject from body with a blank line (Already implemented)
• Limit the subject line to 50 characters (#6)
• Capitalize the subject line (#7)
• Do not end the subject line with a period (#11)
• Use the imperative mood in the subject line (This can be shown and suggested with examples) (Related #10)
• Wrap the body at 72 characters (#6)
• Use the body to explain what and why vs. how (This can be suggested in the question) (#12)

The bold items are things I think are easily enforceable based on the commitzen framework. Number 5 might be something we can highly suggest using examples. And number 7 can be optional, but I guess you could break up the commit message as "What changes did you make" + "Why and how did you make this change".