Commitlint: Commitlint broken due to minimist upgrade

[bohdan-shulha]

Expected Behavior

Commitlint works

Current Behavior

Commitlint doesn't work

Affected packages

• [ ] cli

Possible Solution

Patch default values of the flags so default types match flag types (https://github.com/marionebl/commitlint/blob/master/%40commitlint/cli/src/cli.js#L16)

Steps to Reproduce (for bugs)

1. Install commitlint
2. Run git commit
3. See TypeError: Expected "config" default value to be string, got object

Context

Here is an PR on the minimist https://github.com/vadimdemedes/minimist-options/pull/8

Your Environment

| Executable | Version |
| ---: | :--- |
| commitlint --version | 7.3.2 |

[escapedcat]

Hey @bohdan-shulha , I would like to help but I would need some more input from you regarding what your issue is. Maybe you can point to an exmaple repo we could take a look at or provide more information. Thanks.

[marionebl]

Closing for now, feel free to reopen if the problem pops up again.

[bniedermeyer]

@escapedcat @marionebl I'm running into this issue as well - maybe it can be reopened?

Here's the stack trace of the error I see

$ git commit -m "foo: this should fail" 

husky > commit-msg (node v10.15.3)
/commitlint-issue-544/node_modules/minimist-options/index.js:74
                                        throw new TypeError(`Expected "${key}" default value to be ${type}, got ${typeof props.default}`);
                                        ^

TypeError: Expected "config" default value to be string, got object
    at Object.keys.forEach.key (/commitlint-issue-544/node_modules/minimist-options/index.js:74:12)
    at Array.forEach (<anonymous>)
    at module.exports.options (/commitlint-issue-544/node_modules/minimist-options/index.js:36:23)
    at module.exports (/commitlint-issue-544/node_modules/meow/index.js:60:20)
    at Object.<anonymous> (/commitlint-issue-544/node_modules/@commitlint/cli/lib/cli.js:100:13)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
husky > commit-msg hook failed (add --no-verify to bypass)

At first I thought I might have had a conflicting dependency that called a different version of minimist-options but when I checked my project I got the following

$ npm ls minimist-options
/commitlint-issue-544
└─┬ @commitlint/[email protected]
  ├─┬ @commitlint/[email protected]
  │ └─┬ @commitlint/[email protected]
  │   └─┬ [email protected]
  │     └─┬ [email protected]
  │       └── [email protected]  deduped
  ├─┬ @commitlint/[email protected]
  │ └─┬ [email protected]
  │   └─┬ [email protected]
  │     └── [email protected]  deduped
  └─┬ [email protected]
    └── [email protected]

I've created a repo with a reproduction I used for the above code snippets: https://github.com/bniedermeyer/commitlint-issue-544

Commands to recreate:

1. npm ci
2. touch my-new-file
3. git add my-new-file
4. git commit -m "feat: add my-new-file

[byCedric]

@bniedermeyer First of all, thanks a lot for the extensive documentation and example repository! This helps us a lot trying to find the source of all this! ❤️ I'll reopen the issue. I'll try to get some time available tomorrow evening (CEST) to see why this happens and how we can fix it!

[byCedric]

One thing I just noticed is that [email protected] appears to be _removed_ from the NPM registry while it should exist, but I don't know why. It could be possible that this exact version is causing some issues, and therefore was removed. _If_ this is true, I think it would be best for us to upgrade all dependencies to the latest version asap to use the latest meow (if possible and not done already). But again, I'll look into this further tomorrow!

---

After running npm ci on the example repo provided by bniedermeyer:

npm ERR! code ETARGET
npm ERR! notarget No matching version found for [email protected]
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

After I try to install the example repo with yarn, it does seems to work. But that's because yarn is installing the older versions of the package:

yarn list | grep minimist-options 
│  │  ├─ minimist-options@^3.0.1
│  ├─ minimist-options@^3.0.1
├─ [email protected]

[bniedermeyer]

@byCedric Interesting! It looks like that version was unpublished not long after the issue was opened. https://github.com/vadimdemedes/minimist-options/pull/8#issuecomment-455529014

I probably didn't notice that because I was pointing at a private registry that would have it cached when I was building the repro.

[byCedric]

Ah, that could definitely explain it! Thanks for linking the comment! ❤️ Couldn't find it myself.

Well, one thing that we can do is try to bump all dependencies to the latest versions to get the 3.x.x version fully out of our dependency chain. It might be a long shot and not fully possible (yet), but that should solve this once and for all. Could take a while though.

Were you able to get your thing working with this?

[bniedermeyer]

Unfortunately no - we had to disable commitlint for the time being. I haven't had time to investigate whether something like rolling back to an earlier version would fix the problem.

[byCedric]

Ok, I asked if the guys from minimist-options can re-publish their 3.0.2 as 3.1.1. I hope he agrees, if not we need to figure out something else. This way, your private repository _should_ perfer the republished 3.0.2, practically faking and auto-performing the rollback for all private repositories.

[bniedermeyer]

Oh that would be great. Thanks!

[byCedric]

Well, in the end, the maker wasn't really comfortable in republishing the package as 3.1.1. The thing anyone should do when encountering this message is purging the faulty version from the private registry I guess. Sorry for the maybe unsatisfying end Brenden!

[bniedermeyer]

@byCedric No problem - thanks for your help. Just to clarify the procedure to fix this for those with private registries should be:

1. purge the bad version from the cache
2. reinstall so the fix is picked up by the registry

[byCedric]

@bniedermeyer yes, that's it! Remove it from the private registry and it should resolve the (working)-older version. 😄 Good luck and let us know if we can help more! 😄