Summary
The docs for vitest/expect-expect state that the default assertFunctionNames list is ["expect", "expectTypeOf", "assert", "assertType"]. Supplying that same list explicitly in the config changes the rule's matching behavior as chained method-call assertions like supertest's await request(app).post('/').send(body).expect(501) are flagged as "Test has no assertions", even though the rule with no override (i.e. relying on defaults) correctly recognizes them as assertions.
Reproduction
A single test file that uses supertest's chained .expect():
// repro.test.ts
import express from 'express'
import supertest from 'supertest'
const app = express()
app.use(express.json())
app.post('/', (_, res) => res.status(501).send())
describe('supertest chained expect', () => {
it('returns 501 for the request body', async () => {
await supertest(app).post('/').send({ foo: 'bar' }).expect(501)
})
})
Case A - implicit defaults (passes ✅)
// oxlint.config.ts
export default defineConfig({
plugins: ['vitest'],
rules: {
'vitest/expect-expect': 'error'
},
})
oxlint repro.test.ts → 0 errors
Case B - explicit defaults exactly as documented (fails ❌)
// oxlint.config.ts (excerpt)
export default defineConfig({
plugins: ['vitest'],
rules: {
'vitest/expect-expect': [
'error',
{ assertFunctionNames: ['expect', 'expectTypeOf', 'assert', 'assertType'] },
],
},
})
oxlint repro.test.ts → reports:
repro.test.ts:9:3: error vitest(expect-expect): Test has no assertions
help: Add assertion(s) in this Test
Expected
Setting assertFunctionNames to the documented default list should be a no-op, the rule should report the same diagnostics as with no override.
Actual
Providing any explicit assertFunctionNames value (including the documented default) switches the rule to a stricter matching algorithm that no longer treats *.expect() deeper than one chain segment as an assertion.
Impact
Users who want to extend the assertion list have no documented way to do so without simultaneously changing detection on chained .expect() calls.
Summary
The docs for
vitest/expect-expectstate that the defaultassertFunctionNameslist is["expect", "expectTypeOf", "assert", "assertType"]. Supplying that same list explicitly in the config changes the rule's matching behavior as chained method-call assertions likesupertest'sawait request(app).post('/').send(body).expect(501)are flagged as "Test has no assertions", even though the rule with no override (i.e. relying on defaults) correctly recognizes them as assertions.Reproduction
A single test file that uses supertest's chained
.expect():Case A - implicit defaults (passes ✅)
oxlint repro.test.ts→ 0 errorsCase B - explicit defaults exactly as documented (fails ❌)
oxlint repro.test.ts → reports:
repro.test.ts:9:3: error vitest(expect-expect): Test has no assertions
help: Add assertion(s) in this Test
Expected
Setting
assertFunctionNamesto the documented default list should be a no-op, the rule should report the same diagnostics as with no override.Actual
Providing any explicit
assertFunctionNamesvalue (including the documented default) switches the rule to a stricter matching algorithm that no longer treats*.expect()deeper than one chain segment as an assertion.Impact
Users who want to extend the assertion list have no documented way to do so without simultaneously changing detection on chained
.expect()calls.