The rule @typescript-eslint/strict-boolean-expressions breaks code on --fix

[fasenderos]

What version of this package are you using?
ts-standard: 12.0.2
which under the hood use eslint-config-standard-with-typescript: ^23.0.0

What operating system, Node.js, and npm version?
Node: 18.16.1
npm: 9.5.1

What happened?
code before fix

type Items = {
    foo: string
}
const items: Items[] = [
    {foo: 'bar'},
    {foo: 'bar'},
]
function someFn (items?: Items[]) {
    return JSON.parse(
        JSON.stringify(items || []),
    );
}
const test = someFn(items)
console.log(test); // [ { foo: 'bar' }, { foo: 'bar' } ]

code after ts-standard --fix

type Items = {
    foo: string
}
const items: Items[] = [
    {foo: 'bar'},
    {foo: 'bar'},
]
function someFn (items?: Items[]) {
    return JSON.parse(
        JSON.stringify((items != null) || []),
    );
}
const test = someFn(items)
console.log(test); // true

After digging a lot I found the issue comes from the allowNullableObject of the @typescript-eslint/strict-boolean-expressions rule here

What did you expect to happen?
Code gets changed with the ?? operator.

Are you willing to submit a pull request to fix this bug?
yes, if it means remove the allowNullableObject option from the rule

Similar issue 226

[fasenderos]

Bug reported to typescript-eslint. In the meantime can you consider removing this option?

[mightyiam]

Should this project remove this rule because fixing breaks code? What's the alternative? This is made somewhat worse by us not being able to bump the dependency, yet.

[fasenderos]

Until typescript-eslint fix that problem I can't see alternative. Finding the breaking code in a linted file with hundreds modifications it's really hard IMHO

[fasenderos]

typescript-eslint fix that problem in v6.4.0 (#7394) by replacing the dangerous fix with suggestion. @mightyiam the dependency can be updated?

[mightyiam]

Although this package does not compel you to install v6.4.0, now it does not prevent you from doing so, either. Would you consider this issue closed, or would you suggest we bump the peerDep to v6.4.0 ?

[fasenderos]

For better user experience, which ensure that a code fix does not break existing functionality, I think that issue can't be closed until v6.4.0. Anyway thanks for your great work

[fasenderos]

I didn’t notice that now the devDep is 6.4.0 while only the peerDep is 6.1.0.
So I think that this issue can be closed, unless you want to keep it open as a reminder.
Thanks

[mightyiam]

@fasenderos would you contribute a change that bumps the peerDep to the one with the fix? It would be kind to prevent users from experiencing this, right?

[fasenderos]

Sure