[feat] Ability to "Ignore" Certain Errors

[JHWelch]

Hello! I really like how this project surfaces suggestions. It has been very helpful for fixing issues with my modules.

The perfectionist in me wants to be able to work through the entire list, but occasionally there are items that for whatever reason I may choose to not resolve, or are not relevant to the current module.

Would you be open to a sort of "Ignore" list? Similar to ESLint ignores or similar features in static analysis tools.

Proposed process

Parsing ignores inline may be fairly difficult, but we could add something like a .mmmignore file with a list of identifiers. Then give each error a unique, preferably immutable, id. So copy changes don't become breaking changes to the ignore file.

I think this could be relatively straight forward to add something like this. the addIssue would track issues as a Map instead of just an array, and then at the end of processing, remove all keys found in .mmmignore.

If there is any appetite for this as a feature I would not mind taking a stab at it, let me know!

[KristjanESPERANTO]

Thanks for the positive feedback and the suggestion! I'm generally open to improving how we handle exceptions. Currently, we have centralized exception lists (like README_MODULES_FALSE_POSITIVES) that we maintain in this codebase.

Before deciding on an approach, I'd like to better understand the use cases. Could you share specific examples of checks you'd want to ignore for your modules?

I see two possible approaches:

1. Your proposal: Module-level .mmmignore file in each repository

   • ✅ Self-service for maintainers
   • ⚠️ Risk: Maintainers might disable valuable recommendations too easily

2. Alternative: Centralized exception requests with justification

   • Maintainers submit a request (e.g., via issue/PR) to add their module to exception lists
   • Must include reasoning for each ignored rule
   • ✅ Maintains quality control through review process
   • ✅ Creates documentation of why certain checks don't apply
   • ⚠️ Less convenient, requires approval

What are your thoughts?

[JHWelch]

@KristjanESPERANTO Good questions! I think that makes a lot of sense, I similarly wouldn't want it to be easy to ignore errors, especially for ones that are particularly important.

I see there are some different prefixes used for different types of issues, some with "Recommendation".

So maybe another approach would be some sort of happy medium where there are core issues you can't ignore without an exception request, and then there are Recommendations that you can decide to ignore.

examples

The two examples I've had, that might land in these two categories are:

slimify

on MMM-CTA I tried out the gh slimify, and my workflows still worked, but they took over twice as long as my normal workflow runs and I think for now I am not going to use them, as the repo is public and the cost savings are not relevant here.

As this recommendation does not effect the actual performance of the module, I would love to be able to get to a coveted "no issues" without having to make this change.

CDN for non-module code

The other example is on MMM-NotionCalendar where I have a somewhat odd module simply provides an endpoint using node_helper that is customized through a query string instead of the traditional config.

Because this is a particularly annoying user flow, I added a simple webapp that helps you form the URL for local use.

This page is not otherwise used for the actual module execution, and because it is not a high risk site, it was easier to thrown in a CDN link instead of adding all the code I'd need for a nice bundler for a docs/ page.

thoughts

So I definitely think the "don't use a CDN" error is something worth forcing a dev to ask for an exception, but if you're going to add more opinionated things like the ubuntu-slim images, then maybe those should be more simply opt-out-able.

[KristjanESPERANTO]

@JHWelch Good point about the CDN vs. slimify distinction!

Quick question though: We already state at the top of result.html that "Some issues are opinionated recommendations. Please feel free to ignore them."

Would better visual distinction in the output (e.g., prefixing recommendations with 💡 instead of just listing them) be enough?

The main work would be in buildMarkdown() in scripts/check-modules/index.ts – rules already have category: "Recommendation" in rule-registry.js.

[JHWelch]

Yeah, I think somehow having recommendations indicated separately from "issues" might be nice.

I think what I'm reacting to in part is the fact that there is the statistic table there, and it seems there is only 1 module "without issues". (I thought it was 0, someone must have fixed up a repo!)

Especially if we want to surface these in the frontend of the main list itself, it would be nice to have a goal of getting to some sort of This module has no issues state. Even if it still has a few "Recommendations".

Though maybe we would still want to tell devs about the recommendations until they at least manually acknowledge they are ignoring them, which is how I had ended up at the ignore file in the first place.

[KristjanESPERANTO]

@JHWelch That makes sense. The goal of reaching "0 issues" is a good motivator.

This would require changes to:

1. Backend: Separate tracking of issues vs. recommendations
2. Data schema: Add recommendations field to modules.json
3. Frontend: Display recommendations separately
4. Statistics: Count only issues in "modules with issues"

What do you think?

[JHWelch]

@JHWelch That makes sense. The goal of reaching "0 issues" is a good motivator.

This would require changes to:

1. Backend: Separate tracking of issues vs. recommendations
2. Data schema: Add recommendations field to modules.json
3. Frontend: Display recommendations separately
4. Statistics: Count only issues in "modules with issues"

What do you think?

Yeah I think that makes sense. One thought I would have is that it might make the most sense to get the issues converted to a (typed) object instead of creating a separate list of recommendations vs issues.

I think that will serve the app more in the long run, in case there are any other pieces of information we could start tracking. So start with something like a "type" and "message" and then just filter at the end of the process.

[KristjanESPERANTO]

@JHWelch Great point! Converting issues to structured objects is definitely the better long-term solution.

Quick thought: If we add a ruleId field, we could keep the structure minimal and look up metadata (like category) from the rule registry:

{
  "issues": [
    {
      "ruleId": "pkg-missing-dependency",
      "message": "Missing dependency: axios"
    },
    {
      "ruleId": "workflow-ubuntu-slim",
      "message": "Consider using ubuntu-*-slim images"
    }
  ]
}

This way:

• The category (issue vs. recommendation) lives in the rule registry, not duplicated in the JSON
• Ignore lists can reference stable IDs instead of message strings
• Frontend can filter/group by looking up the rule

What do you think? Or would you prefer to include category directly in the JSON for easier consumption?

Implementation-wise, this would change the issues field format in modules.json, requiring updates to schema, backend, and frontend.