Quick review of existing structure before we move onto adding more rules. about addons-linter

[tofumatt]

Which do you prefer? I realised I was doing class methods in the HTML parser but even now I’m now sure I like it, and I could see it getting crazy out of hand (a file with a thousand lines? :-/) pretty fast. Should we be moving to a list of rules in a folder that we import as functions? Something like     - rules       - html         - mustNotExist.js         - idIsRequired.js       - js         - eval.js         - mozIndexedDB.js etc.?

[muffinresearch]

Yeah I went something along the lines of that direction with the CSS scanner as I thought the eslint style of rule funcs seemed quite a nice approach.

A file per rule might be a bit much but depends it might be best if there are loads.

As a side note I noticed coverage didn't seem to see the js rules but I suspect that's because they're not directly imported due to eslint.

[muffinresearch]

Definitely, something in the back of our minds should be making it super easy for new rules to be added. This way it will make it much easier to get help with the not insignificant amount of rules that need to be implemented.

[tofumatt]

Ah. That would be a problem. I could probably import them directly and feed them the kind of data ESLint expects, but the rules do get tested. I’d rather not tell the coverage checker to ignore that folder, but the rules are tested via eslint and not directly, true.

[tofumatt]

Okay cool, I'll move the #70 rules to that "rule-per-file" style, as well as the RDF ones: #79.

[tofumatt]

We assessed a fair bit of stuff and made it better... we can close this now I think. Thoughts @muffinresearch?

[muffinresearch]

Yep lets close this and raise issues for specifics.