Frequently Asked Questions
My repo CI already have linters and they're perfectly working, so why do I need MegaLinter ?
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 MegaLinter with DISABLE: JAVASCRIPT
. That way, you will benefit from both your installed linters but also from 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 just a selection of linters if you are using a MegaLinter 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)
- except files in ignored folders (
- 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)
- List all project files:
- 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…)
- Parallelly, for each linter with matching files:
- 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
- 0 if no error (or only non blocking errors if user defined