bahmutov / simple-commit-message Goto Github PK

Simple commit message wizard and validator; works with commitizen and pre-git

JavaScript 100.00%

commitizen semantic-versioning semantic-release

simple-commit-message's Issues

Add "minor" type

It makes sense to allow feature versions as

minor(something): add something feature

Vulnerable `debug` package

Hey there! 👋

I use this package in few places, and in one of them NSP reports that debug is older version that has ReDDoS vulnerability.

I am seeing that here is no debug as dependency but for some reason the NSP report mention that package, so.. don't know.

https://nodesecurity.io/orgs/tunnckocore-dev/projects/b8ccbfa6-282e-4360-aee5-1497dc059e6b/4

Probably some of your deps uses old debug? Don't know. How can we fix such issues? Probably to install debug in my package temporary?

Can we use as analyzeCommits plugin for semantic-release

https://github.com/semantic-release/semantic-release#analyzecommits

in package.json

{
  "release": {
    "analyzeCommits": "simple-commit-message"
  }
}

then our module should export the following signature

module.exports = function (pluginConfig, config, callback) {}
// config.commits is the list of commits
// should call callback with 'major', 'minor', etc

Auto install as release plugin on postinstall

Just like bahmutov/github-post-release#5

simple-commit-message does not ignore comment line i.e. lines that start with '#'

We have a commit message template we add to projects so devs know the format of the commit message when writing their commit messages.

This commit message should not fail since '#' should be ignored:

# Type(<scope>): <subject>
chore: add git hooks for testing before pushing
# <body>
# <footer>

# Type should be one of the following:
# * feat (new feature)
# * fix (bug fix)
# * docs (changes to documentation)
# * style (formatting, missing semi colons, etc; no code change)
# * refactor (refactoring production code)
# * test (adding missing tests, refactoring tests; no production code change)
# * chore (updating grunt tasks etc; no production code change)
# Scope is just the scope of the change. Something like (admin) or (teacher).
# Subject should use impertivite tone and say what you did.
# The body should go into detail about changes made.
# The footer should contain any tool issue references or actions.

# For a full example of how to write a good commit message, check out
# https://github.com/sparkbox/how_to/tree/master/style/git

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch chore/reset_to_clean_src
# Changes to be committed:
#       modified:   package.json
#       modified:   yarn.lock

yet it does with this:

INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" ! was: # Type(<scope>): <subject>
chore: add git hooks for testing before pushing
# <body>
# <footer>

Detect commit messages in the squashed commit

For example see bahmutov/generator-node-bahmutov@8eb48ad

The subject is just Immutable (#57) but the body has titles from 3 commits that were squashed from the pull request. One of them is semantic commit! Should detect such commits and return valid list

* feat(immutable): optional immutable linter, close #56

* add immutable to E2E answers

* add note to readme

Postinstall script interferes with semantic-release config

Hi, I had a really annoying debug session :/

If installing simple-commit-message with semantic-release and configuring semantic-release in a .releaserc file the post-install script of this plugin modifies the package.json file each time I am doing an npm install (which is every build, as it thinks there is no release configured).
The problem now is that the release config in the package.json takes precedence over the .releaserc config and in this way uses the standard configuration every build.

In order to solve this problem there are multiple ways:

(My favorite) Remove the Postinstall script.
- Just provide a configuration example in the README.md as every other plugin or package.
- Adding a "release" option isn't that hard. (Maybe I can refactor the postinstall script into a cmd command, so it is still easy to install)
Make it agnostic to .releaserc files.
- Maybe there are some other config formats I or We couldn't think of, than we will start over again.
At least provide a Environment variable to not execute the postinstall script.

Please choose one of the above actions and I will try my best to provide a PR for it. Thanks!

Suggestion: factor out the message validation

Just like #3

Make compatible with semver

Allow commit messages that are plain semver numbers, see bahmutov/pre-git#70 for details

Set up semantic release using GitHub Actions

Since Travis is not working very well

Very strange case (when bumping major) - problem with the body?

Can't think for some more meaningful title, sorry.

In last hour and two, i'm updating one of my repos, so i included semantic-release, simple-commit-message and github-post-release.

I pushed a fix type commit with Yes answer of Is this major breaking change? question.

And from the console

Line 1 will be cropped at 100 characters.
All other lines will be wrapped after 100 characters.

? Select the type of change that you're committing: fix:      A bug fix
? Denote the scope of this change (db, api, cli, etc.):
 refactor
? Write a short, imperative tense description of the change:
 require Node >= 7 (because koa-send@4); simplify
? Provide a longer description of the change:
 rewrite from scratch; fix bugs; update build process, npm scripts & boilerplate stuff
? List issues this commit resolves (fixes #2, closes #14):
 fixes #4, resolves #5
? Is this a major breaking change:
 Yes
? Should this be published under different tag?
  This will let users still install the current latest,
  but eary adapters can `npm install <name>@<tag>`
 latest
formed the following commit message
======================================================================================================================
fix(refactor): BREAKING CHANGE: require Node >= 7 (because koa-send@4); simplify

BREAKING CHANGE
rewrite from scratch; fix bugs; update build process, npm scripts & boilerplate stuff
TAG: latest

fixes #4, resolves #5
----------------------------------------------------------------------------------------------------------------------
? Do you want to commit? Yes

And as you see, semantic release published patch version, instead of major. Initially, it was absolutely shock for me, because in first look everything looks okey. But when you look more carefully you may see that the body's BREAKING CHANGE does not have color (:), which i believe caused semantic release to not understand really that this is major change.

For first time i'm bumping major with this package, instead of commitizen. Probably you too? Because if i remember correctly the important thing is that it must be BREAKING CHANGE: in the body. It's not important for semantic-release and (previously used by me) standard-version -- adding it to the title is just a stylistic thing for the users to see it more easy.

All this caused me a bit headache, because need to back to the prev commit, delete release/tag and unpublish that version from npm.

Add method to check if commit is major + minor + fix

For quick filtering of non-semantic and chores

Add `body` of the commit in the result object

As like we have subject and type, so we should have body too. ;)

Make compatible with `semantic-release` 11.x plugin system

Old plugin format (as of this writing, still referenced as current in the semantic-release README):

function (pluginConfig, config, callback)

New format:
async function (pluginConfig, config)
or
function (pluginConfig, config) returning Promise

https://github.com/semantic-release/semantic-release/releases/tag/v11.0.0

Add "patch" type

Should be an alias to 'fix'

Trim the message before validating semver

We can get newlines, which are invalid

Support for Uppercased and all oTHeR-cased prefixes?

Hello! We're using the plugin in our projects and noticed that sometimes it's not triggering a release because the prefix is not lowercased. Did you consider supporting MAJOR:, Major: and MaJoR: kinds of cases? I think it should be a small thing to implement. I'm actually a bit surprised that nobody asked about that before (as far as I can see)... Please let me know about your opinion on this topic. Thank you!

INVALID COMMIT MSG: "refactor" is not allowed type !

According to the image below, "refactor" is a valid commit type in commitizen, alongside with "perf", "test", "style" and "docs".
https://raw.githubusercontent.com/commitizen/cz-cli/master/meta/screenshots/add-commit.png

Using "refactor" displays the error in the title, when I use the latest version of git-pre.

Fix release

Currently getting the following error when trying to release a new version, see https://travis-ci.org/bahmutov/simple-commit-message

[13:32:09] [semantic-release] › ✖  Failed step "analyzeCommits" of plugin "simple-commit-message"
[13:32:09] [semantic-release] › ✖  An error occurred while running semantic-release: { TypeError: cb is not a function
    at analyzeCommits (/home/travis/build/bahmutov/simple-commit-message/node_modules/simple-commit-message/src/analyze-commits.js:34:3)
    at simple (eval at <anonymous> (/home/travis/build/bahmutov/simple-commit-message/node_modules/simple-commit-message/src/index.js:12:17), <anonymous>:2:25)
    at validator (/home/travis/build/bahmutov/simple-commit-message/node_modules/semantic-release/lib/plugins/normalize.js:34:30)
    at pReduce (/home/travis/build/bahmutov/simple-commit-message/node_modules/semantic-release/lib/plugins/pipeline.js:37:40)
    at Promise.all.then.value (/home/travis/build/bahmutov/simple-commit-message/node_modules/p-reduce/index.js:16:10)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7) pluginName: 'simple-commit-message' }
{ TypeError: cb is not a function
    at analyzeCommits (/home/travis/build/bahmutov/simple-commit-message/node_modules/simple-commit-message/src/analyze-commits.js:34:3)
    at simple (eval at <anonymous> (/home/travis/build/bahmutov/simple-commit-message/node_modules/simple-commit-message/src/index.js:12:17), <anonymous>:2:25)
    at validator (/home/travis/build/bahmutov/simple-commit-message/node_modules/semantic-release/lib/plugins/normalize.js:34:30)
    at pReduce (/home/travis/build/bahmutov/simple-commit-message/node_modules/semantic-release/lib/plugins/pipeline.js:37:40)
    at Promise.all.then.value (/home/travis/build/bahmutov/simple-commit-message/node_modules/p-reduce/index.js:16:10)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7) pluginName: 'simple-commit-message' }npm ERR! code ELIFECYCLE

Can we factor out the wizard / etc

And only leave the questions in this repo?

Wizard seems to fail on node 8?

Hey! Great modules by you! :)

But i feel this fails from node 8

/usr/bin/env: ‘node --harmony’: No such file or directory

if manually edit the bin file and remove the --harmony flag it works. Strange.

Add breaking / major type

For simple one line breaking change parsing, it would be nice to just do

major(something): rewrote API, breaking(something): rewrote API, break(something): rewrote API

https://github.com/semantic-release/semantic-release#major-breaking-release

should add BREAKING CHANGE to the commit message body

Ask the user what tag should be used

Read from package or use default "latest"

https://medium.com/greenkeeper-blog/one-simple-trick-for-javascript-package-maintainers-to-avoid-breaking-their-user-s-software-and-to-6edf06dc5617#.6yjw2gttx

"publishConfig": {
    "tag": "next"
}

put it in the body of the commit message under TAG:

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Warning

These dependencies are deprecated:

Datasource	Name	Replacement PR?
npm	`dependency-check`

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

fix(deps): update dependency word-wrap to v1.2.5
chore(deps): update actions/checkout action to v4
chore(deps): update dependency ubuntu to v22
fix(deps): update dependency inquirer to v10
🔐 Create all rate-limited PRs at once 🔐

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

fix(deps): update dependency lazy-ass to v2

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions

.github/workflows/ci.yml

actions/checkout v2

bahmutov/npm-install v1

cycjimmy/semantic-release-action v2

ubuntu 20.04

npm

package.json

check-more-types 2.24.0

debug 4.3.4

ggit 2.4.12

hr 0.1.3

inquirer 6.5.2

inquirer-confirm 2.0.7

largest-semantic-change 1.1.0

lazy-ass 1.6.0

semver 5.7.1

word-wrap 1.2.3

ban-sensitive-files 1.9.18

dependency-check 3.4.1

deps-ok 1.4.1

git-issues 1.3.1

next-update-travis 1.7.1

pre-git 3.17.1

ramda 0.28.0

rocha 2.5.10

semantic-release 17.4.7

snap-shot 2.17.0

standard 12.0.1

Check this box to trigger a request for Renovate to run again on this repository

Seems like "Is this major breaking change?" does nothing (almost)

More specifically said, it does, but that adding of BREAKING CHANGE to body and title seems almost useless. Or at least not make sense to output that prompt every time for every kind of type.

Not to mention that the wizard (the prompts) doesn't have break / major and etc. It would be good to at least have major because it seems that semantic-release don't care about the wordings, but care only about major type, which is awful, but anyway.

Add bin command

To run the wizard, and maybe commit?

set up renovate app

to keep dependencies up to date

bahmutov / simple-commit-message Goto Github PK

simple-commit-message's Issues

Rate-Limited

Edited/Blocked

Open

Detected dependencies

Recommend Projects

Recommend Topics

Recommend Org