Discussion: custom configuration

[z0al]

I would like to discuss what things I need to consider when supporting custom configuration files in the root repository directory.

More specifically, how can we support .commitlint.yml or .commitlint.json ? I can't see any way to support .js based config files

Any input is welcome!
cc @marionebl

[marionebl]

I rolled this around a bit already here are my thoughts:

1. Look up .?commitlint.{js,yml.json} and patternplate in package.json via the Github API instead of FS
2. Load the contents of first match via Github API
   3a) .yml and .json: parse the files
   3b) .js: Idea: Run the script in a safe node sandbox with most features and APIs (e.g. require) disabled/limited
3. Resolve relative .extends and .parserPreset, goto 2
4. Use absolute .extends and .parserPreset if they are found in a defined whitelist

cc @paulirish

[z0al]

@marionebl Thank you for sharing this

Look up .?commitlint.{js,yml.json} and patternplate in package.json via the Github API instead of FS

I have no idea what patternplate is and how it's related to commitlint?

[marionebl]

Whoops, I meant commitlint, referring to the feature of cosmiconfig where config is read from a section in package.json

[marionebl]

I do not have a good solution for making this work with things like commitlint-config-lerna though without cloning the repository.

[marionebl]

I understand correctly now.sh is the primary deployment target for probot?

[z0al]

I think a command line approach ( like how bundlesize works) may fits things like commitlint-config-lerna

I understand correctly now.sh is the primary deployment target for probot?

I may only use now.sh - at least for now. Other services are forbidden in my country :/

[z0al]

Here is a another approach:

• Standalone CLI
  Only runs in a CI (i.e. Travis, Circle .etc) environment. It executes commitlint targeting the pre-cloned repo and send the report to our API endpoint! Done (similar to the way code coverage services like https://codecov.io work?)
• The web service (the current bot)
  Its only function is to analyze the report then update the PR status accordingly! it wouldn't be necessary listen to GitHub's webhooks anymore

What do you think?

[marionebl]

Sounds like a very good idea! This would require json formatted output for commitlint and some tool to manage the transport to commitlint-bot right?

[marionebl]

I'd add the complete resolved config to the json output. This way we could even cover @paulirish's use case of linting the PR title, using said resolved config from CI runs to check on title changes indicated by web hooks.

[paulirish]

yo guys! haha it's another commitlint bot! :D

my project is, yah, only focused on the PR title and doesn't care about commits. As such, it wouldn't make sense to be a CLI that runs inside of CI (like codecov or bundlesize). Because a user needs to iterate on the PR title a few times to get it right.. so it needs to be webhook.

In mine, I pull the commitlint.config.js from the root of the repo: https://github.com/paulirish/commitlintbot/blob/9368713fa237a983155d9f57906d0797931e9063/index.js#L33-L37 a little janky but it works.

[z0al]

In mine, I pull the commitlint.config.js from the root of the repo

@paulirish umm, it may not work for commitlint-config-lerna though

[z0al]

It may also limit the possible supported scenarios?

However, you're right, running inside a CI wouldn't make sense if the user only wants title linting