`@kikd/lint-commit` for replacing commitlint

[RayBenefield]

Expected Behavior

We need our own package to lint our own style of commits.

Current Behavior

We are currently using Commitlint, but the scopes should be specifically based on our packages.

Possible Solution

Should just require using commit-parser and then checking if anything came out.

Context

I'm sick of having to add a new package scope to the commitlint.config.js and #197 is only temporary. We need something that matches our style.

[marionebl]

Hey there, you should be able to do a dynamic scope-enum based on your packages by something like (pseudo code)

// commitlint.config.js
const globby = require('globby');

module.exports = {
  rules: {
    'scope-enum': ctx => [2, 'always', getPackages(ctx)]
  }
};

function getPackages(ctx) {
  const ctx = context || {};
  const cwd = ctx.cwd || process.cwd();

  return globby.sync('src/**/index.js', {cwd})
    // Some logic to determine pkg names from fs
   .map(filePath => ...);
}

An example for this approach can be found at marionebl/commitlint/config-lerna-scopes

[RayBenefield]

HEY @marionebl ! I've seen you around the community and it's great to see you here.

What you suggested was essentially the approach I was going to take in #197. Ultimately though I'm looking for something a little more dynamic and custom. Since this is shooting to be an extremely opinionated monorepo tool, I'm able to make some assumptions right off the bat and take advantage of some of that in the linting process.

Here are a few of the things I'm initially looking to build in:

• Because I work on a strictly "independent" versioning, I've found that having multiple changes in a single commit message is very useful. So commits end up having multiple headers with corresponding bodies like https://github.com/RayBenefield/kikd/commit/0151428ec01d820fb59e846f48e06928b76e9818 for example. Replicating that linting for multiple headers in a commit doesn't seem trivial with the https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-commits-parser/lib/parser.js
  • I've already handled most of the parser portion with multiple change support in a single commit in order to handle the current half of the versioning system I'm using right now: https://github.com/RayBenefield/kikd/blob/master/src/node_modules/%40kikd/commit-parser/index.js
• I'm looking to also do scope limiting based on the type of change as well. For example, feat, fix, breaking would all scope to package names, however docs would scope to the name of a document in the docs directory or a package name. Or dx would scope to an existing config files, or a devDependency name.
• When commits are being linted, because of the Alle repo setup I can make assumptions of what the scopes need to exist within the entire commit message based on what the commit's changed files are. Any files under src/node_modules/<package_name> would trigger a check for that package_name scope. Theses scopes could exist across multiple header/body change combinations and I'll need that multi-change parsing in this instance as well for that check.
• I plan on providing a similar tool to Commitizen that will help fill out commits. Since I can look at the changed files and make assumptions, I can pre-fill scopes and ultimately with a tool like that I'll want to make sure the linting exists as a postprocessing portion.

I think I had more reasoning, but I'm blanking right now and need to start tackling some coding before my actual paid work starts today lol...

Regardless, I REALLY appreciate you reaching out @marionebl and the suggestion. I had already planned on adding Commitlint as a part of the prior art section that I plan on writing soonish before making any formal announcement. The work I've seen you do throughout the community through Lerna dog feeding to your whole Commitlint setup, and even just seeing you jump into Rust is absolutely inspiring.

And to double check did you find this repo through the dependents feature of Github? I was a bit surprised to see a comment from someone else on this repo last night lol...

---

EDIT: Also I mapped out a couple of my thoughts on how I want to re-approach versioning, commit message style, and a couple other things in this doc: https://github.com/RayBenefield/kikd/blob/master/docs/versioning.md

Been learning as I go along and haven't really been a part of the open source community (bit of anxiety around participating honestly), so I'm also starting out just trying to pull in as much control over the tools I plan on using because I want to avoid introducing third party dependencies early on as they are a heavy form of tech debt I'd like to avoid while I work towards completing my first real full open source project. I tend to have a massive project graveyard, so the more parts under my full control means more likeliness I'll reach a completion point. So I hope you take no offense to any of the above. :) <3

[RayBenefield]

Adding these for my reference since I need to consider the concept of "footers" since I don't really have them in my vision of versioning right now.

[marionebl]

So I hope you take no offense to any of the above. :) <3

Sure, no offense taken!

I'll try to rephrase your points to make sure I understand them correctly

1. You want parser support for commits with multiple conventional style commits, e.g.

type(scope): something

type: another thing
type2: yet another thing

This one is interesting. Thinking about it we could get away with doing multi-pass parsing runs, feeding each line of a commit body into conventional-commits-parser separately.

2. More sources for scope bounds, e.g. packages/directories changed by the linted commit

That is something I plan to explore a bit with the lerna-* configurations for commitlint too. Pretty sure we could come up with getScopes implemetation that would fit your needs.

All that being said, it boils down to

just trying to pull in as much control over the tools I plan on using because I want to avoid introducing third party dependencies early on

for you. I am not trying to convince you otherwise, just want to point out you could integrate your special use case in the wider ecosystem. Perhaps this serves as valuable reference for a future stage of your project.

---

And to double check did you find this repo through the dependents feature of Github? I was a bit surprised to see a comment from someone else on this repo last night lol...

I do GitHub issue searches for my projects to find issues in the wider community I can help with

[RayBenefield]

@marionebl those are fairly good summations. Ultimately a lot of the work I'll need to do to introduce more automation as a result of the stricter opinionated approach I'm taking for commits will overlap with Commitlint anyway and as I massage out the details I want to make sure I'm not blocked on PRs... the few coding PRs I've put into other projects have expectedly grown stale and I want to avoid that as I explore and iron out what exactly my needs are going to be.

I do plan on eventually taking what I learn and jumping into external projects like Commitlint. But right now I'm working on my transition from proprietary work to open source work so I'm sort of getting my chops ready I guess.

With the setup that I have going right now with the automation around auto-deploys/versioning it is very quick for me to introduce new functionality on my own as I explore what will really work on a large scale. Ultimately the problem I'm trying to solve @marionebl with this repo is more of a company sized "monstrous" monorepo as opposed to a project based one that Lerna solves. I'm taking the automation skills that I learned from my work with companies like Nike and attempting to apply it to open source work. So I will be spending a lot of time experimenting and dropping/adding dependencies rapidly until I find a groove that really works.

I do expect that ultimately the stuff I need will be able to be re-incorporated into Commitlint and then I can switch back to using it and benefiting the community on the whole, but right now I need the flexibility of learning what I'm going to need without also affecting other people's work.

Thanks a ton for reaching out though @marionebl... it definitely means a lot. My anxiety of jumping into the open source community is massive lol. Just sort of trying to get a feel in my own bubble before really branching out, ya know?

[RayBenefield]

Closing #281 as duplicate. Here is its description for reference:

Expected Behavior

While Commitlint is awesome... it doesn't exactly follow the same ruleset as I have now. Plus its sentence case isn't really sentence case... see #32 . So I just need to replace it with my own.

Current Behavior

We rely on Commitlint and the respective commitlint.config.js that I want to remove. The rules are different now since I wrote the #248 versioning documentation.

Context

I want better commit linting. Especially since I just removed the scope enum portion of Commitlint.