Looking for advice in creating new linters, adding linter plugins and maybe creating a flavor for a project

[pessi-v]

Hello,

I'm in a project now, where we'd like to have a set of linters specific to reducing CO2 emissions from software. This would include general performance optimizations, some optimizations that might incur a tradeoff - for example with image resolution, and linter rules that can guide the developer to choose data centres in better locations, or run background jobs in hours of more renewable energy in the grid.

There are some existing linters and linter rulesets we'd like to integrate, such as:

• 'creedengo' SonarQube rules for Java, PHP, Python, C#, Android and iOS
• 'creedengo' JavaScript ESLint plugin
• fasterer for ruby
• rubocop-performance for ruby (already in megalinter I believe)
• ec0lint for JS/css/npx

I'm looking for advice how to move on with implementation. The documentation around this is a bit confusing 🙏

Please help me understand if my current understanding of things is right:

• probably we're looking at creating a "plugin", because our ruleset might not be universally wanted within megalinter
• the only difference between a megalinter Linter and a Plugin, is that a Linter is included by default, whereas a Plugin must be declared in .mega-linter.yml or as an environment variable on the CLI
• the entry point to adding either a Linter, a Plugin, or another ruleset to a Linter already in megalinter, is through a *.megalinter-descriptor.yml file
• there is no process for integrating a plugin - because plugins are not integrated - apart from a PR to update the plugins list on the documentation

is this the workflow for creating a linter/change in an existing linter ?

• create/edit a *.megalinter-descriptor.yml file
• run build.sh
• add a "good" and a "bad" file to .automation/test
• run tests (how?)
• submit PR in case of Linter or a change in existing Linter

is this the workflow for creating a plugin?

• create/edit a *.megalinter-descriptor.yml file
• that's it? It kind of just needs the dockerfile line for installation, and a 'cli_executable' command (broadly, I know there are a few more required fields)

other open questions:

• for linting multiple languages, do we need to implement 1 plugin per language?
• if there is no 'cli_executable' variable in the descriptor, the 'linter_name' will be the command that megalinter runs?
• what is the purpose of having 'descriptor_flavors' for a plugin, if plugins are anyways only loaded by an addition to .mega-linter.yml?

Thank you

[nvuillam]

@pessi-v thanks for your interest in MegaLinter :)

I think that the most optimized solution for you would be the following:

1. Create a custom flavor containing only the official ML linters that you need for your project (beta for now but released in the following weeks)
2. Create ML plugins for each linter that is not in our catalog
3. Use your custom flavor + your plugins that will be referred in your .mega-linter.yml config file

Some answers to your questions:

Please help me understand if my current understanding of things is right:

probably we're looking at creating a "plugin", because our ruleset might not be universally wanted within megalinter
the only difference between a megalinter Linter and a Plugin, is that a Linter is included by default, whereas a Plugin must be declared in .mega-linter.yml or as an environment variable on the CLI
the entry point to adding either a Linter, a Plugin, or another ruleset to a Linter already in megalinter, is through a *.megalinter-descriptor.yml file
there is no process for integrating a plugin - because plugins are not integrated - apart from a PR to update the plugins list on the documentation

Looks good to me :)
Plugins are externally maintained on separate repos, and their use relies on the trust users have in their authors, we don't control them, just add a link in the documentation.

is this the workflow for creating a linter/change in an existing linter ?

create/edit a *.megalinter-descriptor.yml file
run build.sh
add a "good" and a "bad" file to .automation/test
run tests (how?)
submit PR in case of Linter or a change in existing Linter

Yes it is the process :)
But we accept in the official linters only those who are widely adopted by the community and actively maintained (for security reasons)

is this the workflow for creating a plugin?

create/edit a *.megalinter-descriptor.yml file
that's it? It kind of just needs the dockerfile line for installation, and a 'cli_executable' command (broadly, I know there are a few more required fields)

Yes that's it, the format of a plugin descriptor is the same than the format of official linters descriptor
You'll probably need a little bit more properties for a better user experience, like regexes allowing to count errors for example (you can have a look at the existing official descriptors and plugins

for linting multiple languages, do we need to implement 1 plugin per language?

Yes, even one plugin by linter (but you can have multiple plugins descriptors in the same repository.
Think about the community that would like to use one of your linter but not the others :)

if there is no 'cli_executable' variable in the descriptor, the 'linter_name' will be the command that megalinter runs?

Yes it will.
You can have a look in how are built CLI commands there ->

megalinter/megalinter/Linter.py

Line 1375 in 3ca6f8d

def build_lint_command(self, file=None) -> list:

what is the purpose of having 'descriptor_flavors' for a plugin, if plugins are anyways only loaded by an addition to .mega-linter.yml?
Indeed, flavors are for natively embedded linters so useless in the context of a plugin :)

Please let me know if you have other questions :)