`no-array-prototype-extensions` still false-positives on many common mirage.js querying patterns

[hoylemd]

I was quite excited to see https://github.com/ember-cli/eslint-plugin-ember/pull/2331 get merged, as it would allow me to remove a lot of in-line disable comments of the no-array-prototype-extensions rule in my mirage.js files. Unfortunately I've found a couple of cases of mirage findBy that aren't covered by that solution.

• if the call chain starts with server or schema (common in mirage factories and config) and not this. or window., it's still flagged as a violation of no-array-prototype-extensions
  • e.g. server.schema.users.findBy({email: '[email protected]'})
• it still requires both server and schema in the request chain. When defining mocked routes in mirage.config.js, only schema is passed in, not server, so a query would be server.modelName.findBy()
  • e.g. server.users.findBy({email: '[email protected]'})
• records can also be looked up in mirage via server.db.modelName.findBy, bypassing schema. (though I'm not sure this is something to be encouraged).
  • e.g. server.db.users.findBy({email: '[email protected]'})

Could the regex perhaps be tweaked not to require a preceeding ., and only require that server and/or schema are in the request chain? or would that broaden the pattern too much?

[NullVoxPopuli]

is it reasonable to use this.server or this.schema?

globals are kinda 😬 ya? (idk)

[hoylemd]

server or schema aren't globals, they're parameters for afterCreate hooks in mirage factories or route mock handlers. this.server only works in the test functions themselves, not the fixture factory or API mocking