Skip to content

Frequently Asked Questions

My repo CI already has linters and they're working perfectly, so why do I need MegaLinter?

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

OK but… how does it work?

MegaLinter is based on Docker images containing either all linters, or a selection of linters if you use a MegaLinter flavor for a project with a specific language or 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