Requirements for lint rule scheduling

[jldec]

Lint rules are scheduled and evaluated by the sdk.

This issue aims to capture the requirements for a lint report scheduler such that lint reports behave nicely (don't overwhelm the CPU or hog the event loop) while still meeting expectations of delivering correct and up-to-date reports.

additional context in:

• MESDK-29
• MESDK-105
• and https://github.com/opral/monorepo/pull/2792

Requirements

1. Don't schedule or run lint reports if apps don't ask for them E.g. paraglide-js or the maching translate cli.
2. Don't re-run lint reports for every change. E.g. when the are many changes in a short time the effects of those changes on lint reports should be batched or throttled, instead of being naively accumulated and queued.
3. Don't assume that all lint reports need to be stored in memory. Since lint reports are secondary (derived) state, they can be re-evaluated on demand if necessary insead of being treated like primary data.
4. Q: should all lint rules be treated the same way, or are some higher prioity than others?

cc: @martin.lysk1 (please comment in the main GH thread)

[martin-lysk]

1. Don't schedule or run lint reports if apps don't ask for them E.g. paraglide-js or the maching translate cli.

• agree - if no one is subscribing / having an effect on a report no reports should be executed

2. Don't re-run lint reports for every change. E.g. when the are many changes in a short time the effects of those changes on lint reports should be batched or throttled, instead of being naively accumulated and queued.

• agree

3. Don't assume that all lint reports need to be stored in memory. Since lint reports are secondary (derived) state, they can be re-evaluated on demand if necessary insead of being treated like primary data.

• As soon as we have a signal on the report results we will need to keep them in memory. Think of a reactive query like

select 
   * // <-- actual set of messages
from message 
    where messageId in (
      select  
        messageId // <-- reactive list of reports producing messages that match
      from reportsView  
       where lintRuleId = 'dublicated-pattern'
     ) 

While we won't store the report results we will need to have there state in memory to keep track of the signals/events we need to trigger.

4. Q: should all lint rules be treated the same way, or are some higher prioity than others?

• Good question - but lint reports seem to be rather fast (800ms on cal.com) without any optimization. we will execute them in a webworker and at that point we could even parallelize them by splitting them into message batches and lint-ids in the future. I would say this is not needed for now.