Remove classes from Audits? about lighthouse HOT 6 CLOSED

I like it for these shorter audits. When the audits get bigger (which I think they will with things like Speed Index, CRP, etc), then I'd be more inclined to see things a little wrapped up, as opposed to a collection of functions, which is what this would probably give us. In any case, whichever way we go, we'll need to be consistent across all the audits.

This approach currently makes it more difficult for us to ensure that an audit correctly sets its name, tags and description as they're not exposed in a testable way. Making them properties of the function would solve that, but then they'd need to be getters (as they currently are in the class) so they can't be overridden, and that's not really then buying us that much.

from lighthouse.

This approach currently makes it more difficult for us to ensure that an audit correctly sets its name, tags and description as they're not exposed in a testable way

IF we export the object, we can just check the shape of the object exported from the audit to verify.

from lighthouse.

I'm a fan of the reorganization. The current implementation seems over-complicated by using inheritance for what is essentially a mixin of a utility function, which we could just as easily require (although the utility of that utility function is declining as so many arguments get added to it :). Ensuring an Audit interface would get us a compile-time check of required properties (and if we want to, a runtime check can be put in auditor.js). Audit utility functions can easily live on auditor.js (or audit-utilities.js or whatever) and be imported where needed.

In general I'd really like to avoid inheritance unless there's actually a class hierarchy. The implicit importing of functions causes a good bit of mental overhead without a conceptual model to back it up, while a require statement is super clear.

from lighthouse.

Yeah. I do admit it's a bit funny that we are agreeing gathers could use stronger base classes, and meanwhile I'm advocating for removing that structure from audits.. but ... so it goes. 😝

from lighthouse.

I see it, and generally I favor composition over inheritance, I just think it's premature to refactor this. When we know more about the stronger base classes I think we should be in a better position to make the call. As it is it feels like we would be choosing without a fuller picture.

from lighthouse.

works for me.

lets get the perf diagnosis moving to see what parts we need to excercise

closing.

from lighthouse.