Allow for non-standard commitlint config location for v2

kevintyj / prlint

Github PR title checker using Conventional Commits spec on Changesets

BSD 3-Clause "New" or "Revised" License

4 stars 3 forks source link

Allow for non-standard commitlint config location for v2 #22

Open ismay opened 3 days ago

ismay commented 3 days ago

Is there an existing request for this?

[X] I have searched the existing feature requests

Is the feature request related to a problem?

Our commitlint config is not in the standard location (long story). I see that for v2 specifying the commit location has been dropped. That means we'll have to copy the config to the standard location, when it would be more convenient to just point to where it is.

Is the feature request related to a existing bug/RFC?

No response

Describe the solution you'd like

Allow cl-config option again.

What is the definition of done?

When cl-config has been added back, or an equivalent feature or solution exists.

Any solutions considered?

No response

Are you able to assist to bring the feature to reality?

Yes, I can

Anything else?

No response

ismay commented 3 days ago

Actually, feel free to close this. I ended up just going with directly using commitlint cli on CI, so this is no longer needed.

kevintyj commented 2 days ago

@ismay I'm actually genuinely curious what the use case of a non-standard commitlint config location would be? Is this a common use case? I would not mind spending a day to add the ability back...

kevintyj commented 2 days ago

The best case scenario use case of the v2 use case is if you do not have any external rulesets you rely on, or have a compiled config, you can dramatically reduce action times compared to using the cli command on a node environment (37sec -> 16sec for me), compared to using the cli command, which I believe would be much slower as dependencies would have to be fetched...

ismay commented 2 days ago

@ismay I'm actually genuinely curious what the use case of a non-standard commitlint config location would be? Is this a common use case? I would not mind spending a day to add the ability back...

To be honest, I don't think you should add it just on behalf of my specific usecase, as it's a pretty rare one. We have an npm package with the config for distributing it amongst the org. So I'm passing the path to that config. It's not that standard and I'm satisfied just running the cli, so if you ask me I think you should save yourself the trouble of catering to an esoteric usecase. But it's up to you.