Skip to content

Frequently Asked Questions

My repo CI already have linters and they are perfectly working, so why do I need Mega-Linter ?

You can perfectly continue using your installed linters and deactivate them in .mega-linter.yml. For example, in a javascript project using eslint, you can configure Mega-Linter with DISABLE: JAVASCRIPT. That way, you will benefit from both your installed linters but also from other Mega-Linter linters checking JSON, YAML, Markdown, Dockerfile, Bash, spelling mistakes, dead URLs...

Ok but... how does it work ?

Mega-Linter is based on Docker images containing either all linters, or just a selection of linters if you are using a Mega-Linter flavor for a project using a specific language / format

The core architecture does the following:

  • Initialization
    • List all project files:
      • except files in ignored folders (node_modules, etc...)
      • except files not matching FILTER_REGEX_INCLUDE (if defined by user)
      • except files matching FILTER_REGEX_EXCLUDE (if defined by user)
    • Collect files for each activated linter, matching their own filtering criteria:
      • file extensions
      • file names
      • file content
      • <descriptor_or_linter_key>_FILTER_REGEX_INCLUDE (if defined by user)
      • <descriptor_or_linter_key>_FILTER_REGEX_EXCLUDE (if defined by user)
  • Linting
    • Parallelly, for each linter with matching files:
      • Call the linter on matching files (or the whole project for some linters like copy-paste detector)
      • Call activated linter-level reporters (GitHub Status Reporter...)
  • Finalization
    • Call activated global level reporters (GitHub Pull Request Comment Reporter, File.io Reporter, Email Reporter...)
    • Manage return code:
      • 0 if no error (or only non blocking errors if user defined DISABLE_ERRORS or <descriptor_or_linter_key>_DISABLE_ERRORS)
      • 1 if errors