Skip to content

Mega-Linter vs Super-Linter

The hard-fork of Super-Linter to be rewritten in Python is not just a language switch: use of python flexibility and libraries allowed to define lots of additional functions described below

Performances

  • Mega-Linter Flavors allow to use smaller docker images, so the pull time is reduced
  • Thanks to python multiprocessing capabilities, linters are run in parallel, which is way faster than Super-Linter bash script who runs all linters in sequence
  • When the linter allows it, call it 1 time with N files, instead of calling N times with one file

More languages and formats linted

  • C, C++, Copy-Paste detection, GraphQL, JSON & YAML with JSON schemas, Markdown tables formatting, Puppet, reStructuredText, Rust, Scala, Spell checker, Swift, Visual Basic .NET ...

Automatically apply formatting and fixes

Mega-Linter can automatically apply fixes performed by linters, and push them to the same branch, or create a Pull Request that you can validate

This is pretty handy, especially for linter errors related to formatting (in that case, you don't have any manual update to perform)

Run locally

Mega-Linter can be run locally thanks to mega-linter-runner

Reports

Capabilities

  • Accuracy: Count the total number of errors and not only the number of files in error
  • Show linter version and applied filters for each linter processed
  • Reports stored as artefacts on GitHub Action run or other remote files
    • General log
    • One report file by linter

Additional Reporters

Screenshot

Screenshot

Enhanced Configuration

  • Assisted installation and configuration using a yeoman generator and JSON schemas for configuration file

Runner Install

Assisted configuration

  • Configure include and exclude regexes for a single language or linter: ex: JAVASCRIPT_FILTER_REGEX_INCLUDE (src)
  • Configure additional CLI arguments for a linter: ex: JAVASCRIPT_ES_ARGUMENTS "--debug --env-info"
  • Configure non blocking errors for a single language or linter: ex: JAVASCRIPT_DISABLE_ERRORS
  • Simplify languages and linters variables
    • ENABLE = list of languages and formats to apply lint on codebase (default: all)
    • ENABLE_LINTERS = list of linters to apply lint on codebase (default: all)
    • DISABLE = list of languages and formats to skip (default: none)
    • DISABLE_LINTERS = list of linters to skip (default: none)
    • Variables VALIDATE_XXX are still taken in account (but should not be used in association with ENABLE and DISABLE variables)

Enhanced Documentation

HTML doc home

  • One page per linter documentation :
    • All variables that can be used with this linter
    • List of file extensions, names and filters applied by the linter
    • Link to Mega-Linter default linter configuration
    • Link to linter Web-Site
    • Link to official page explaining how to customize the linter rules
    • Link to official page explaining how to disable rules from source comments
    • Examples of linter command line calls behind the hood
    • Help command text
    • Installation commands

HTML doc linter

  • Installation links for related IDEs

HTML doc IDE

  • README
    • Separate languages, formats and tooling formats in the linters table
    • Add logos for each descriptor

Plugins management

For linters less commonly used, Mega-Linters offers a plugins architecture so anyone can publish plugins

Simplify architecture and evolutive maintenance

  • Refactoring runtime in Python, for easier handling than bash thanks to classes and python modules
  • Everything related to each linter in a single descriptor YML file
    • easier evolutive maintenance
    • less conflicts to manage between PRs.
    • Few special cases require a python linter class)
  • Default behaviours for all linters, with possibility to override part of them for special cases
  • Hierarchical architecture: Apply fixes and new behaviours to all linters with a single code update
  • Documentation as code
    • Generate linters tables (ordered by type: language, format & tooling format) and include it in README. (see result)
    • Generate one markdown file per Linter, containing all configuration variables, infos and examples (See examples)
  • Automatic generation of Dockerfile using YML descriptors, always using the linter latest version
    • Dockerfile commands (FROM, ARG, ENV, COPY, RUN )
    • APK packages (linux)
    • NPM packages (node)
    • PIP packages (python)
    • GEM packages (ruby)
    • Phive packages (PHP)
  • Have a centralized exclude list (node_modules,.rbenv, etc...)

Improve robustness & stability

  • Test classes for each capability
  • Test classes for each linter: Automatic generation of test classes using .automation/build.py
  • Setup code coverage codecov
  • Development CD / CI
    • Validate multi-status on PR inside each PR (posted from step "Run against all code base")
    • Run test classes and code coverage with pytest during validation GitHub Action
    • Validate descriptor YML files with json schema during build
    • Automated job to upgrade linters to their latest stable version