#3553 (comment):

I think I found a bug when tsconfig’s exactOptionalPropertyTypes is on. With this setting, optional properties are treated as nullish when accessed but as non-nullish when assigned.

// tsconfig:compilerOptions.exactOptionalPropertyTypes = true

const obj: { prop?: [number] } = {};

obj.prop;
//  ^? (property) prop?: [number] | undefined

obj.prop = [42];
//  ^? (property) prop?: [number]

I have a function that sets the property once and returns it on the first call, but subsequent calls only return it without setting it:

function setOnce(value: number): [number] {
    return obj.prop ??= [value]; // ! @typescript-eslint/no-unnecessary-condition: "Unnecessary conditional, expected left-hand side of `??` operator to be possibly null or undefined."
}

setOnce(1); //=> [1]
setOnce(2); //=> [1]
obj.prop.push(3);
setOnce(1);  //=> [1, 3]

The problem here is that typescript-eslint thinks obj.prop is non-nullish and reports an error, even though it is nullish before being assigned.

I’m not sure what the right solution is. We want to keep --exactOptionalPropertyTypes on to avoid statements like obj.prop = undefined;, but we still want to allow the ??= assignment operator.

Filed a bug with TS - microsoft/TypeScript#53305
IMO this should be fixed in TS itself cos even TS behaves differently with assignment operators vs their expanded form. But we'll see what they say.

If not, then we either must implement our own logic to determine if the LHS might be an exact optional type or not, or we might just disable checks on ??=. First port of call is the types, then we can make a decision about next steps.

@bradzacher — I believe TS is working as intended since after assignment it will be number and not undefined. We’ll see what they say. Regardless, I would add this function to your playground, for completeness:

function ee() {
xx.prop = 1;
//  ^?
// typeof xx.prop === number ❌
}

@chharvey if it was working as intended then += and ??= would work the same way.

(number | undefined) + number === number always (because NaN is a number).
So by your reasoning:

xx.prop += 1
//  ^?
// typeof xx.prop === number, because the result of the assignment operator will always be number

But that's not what we see from TS - we see that TS correctly shows that typeof xx.prop === number | undefined.
Which is why it's inconsistent!

You need to separate the read from the write!
xx.prop has not been updated until after the assignment node is complete and traversed.
i.e.

xx.prop += 1;
            ^ semi = end of expression = assignment complete
              before this point xx.prop has not been updated
              so any intellisense hovers should be the type *before* the write

TS does appear to do this - but from the looks of it TS also does some funny stuff with the type of a variable that has a union type at write time - it appears to invalidate the refinements on the variable at specific write times.

This is filling up my code with a bunch of // eslint-disables. Anything that can be done about this?

This issue hits our team really bad. We're currently working around this with a local patch via pnpm:

diff --git a/patches/@typescript-eslint__eslint-plugin@5.58.0.patch b/patches/@typescript-eslint__eslint-plugin@5.58.0.patch
new file mode 100644
index 000000000..c38427dcd
--- /dev/null
+++ b/patches/@typescript-eslint__eslint-plugin@5.58.0.patch
@@ -0,0 +1,12 @@
+diff --git a/dist/rules/no-unnecessary-condition.js b/dist/rules/no-unnecessary-condition.js
+index 6d36b811889c22e0b6dc61beb40a82671fd47ad4..d0f06ace52ecbffe4b571ebc9d05450dca15a1fb 100644
+--- a/dist/rules/no-unnecessary-condition.js
++++ b/dist/rules/no-unnecessary-condition.js
+@@ -479,7 +479,6 @@ exports.default = (0, util_1.createRule)({
+             }
+         }
+         return {
+-            AssignmentExpression: checkAssignmentExpression,
+             BinaryExpression: checkIfBinaryExpressionIsNecessaryConditional,
+             CallExpression: checkCallExpression,
+             ConditionalExpression: (node) => checkNode(node.test),

It seems like the TypeScript PR microsoft/TypeScript#54777 was merged, which closed the issue in the TypeScript repo:

• exactOptionalPropertyTypes does not include undefined in the type for assignment operators like ??= microsoft/TypeScript#53305 (comment)

Will this mean that this issue will "fix itself" once the TS PR changes are released in a version of TypeScript (eg. maybe 5.2)?

Hello
One of my co-worker had the same issue with this piece of code :
https://typescript-eslint.io/play/#ts=5.2.2&showAST=ts&fileType=.tsx&code=C4TwDgpgBAYghgYwsKBeKBvAUFKBrASwDsATAfgC4oBnYAJ2IHMsBfLLUSKAcToHsArmDSYcUAGaJk1KvCTAA2gF1W7BHyK0oAWxC9BYGT35DlIhWIwSpwIwquFSVAOTA%2Bb51BYAaTCyVe3pbW8nYOxCQuwATRnj5%2BAWwqWOqaKOJ8fCK6%2BkLUYgB04gA2cMAAsnBgABTVMRDaAJRoAHxQ9dpFNtSNhXQQJAJItf3UAsXAvggCdP1EwABqcMUCEM2obdi4uATiUNXTsxDzSysQBY4kzdhi21AA9PdQABYQ-VCCdFDqJNAZdEhqDpoG4oHASCQoMBXlAiHwALQCIhECCA6hwOggeGpEgxAgaW7baqjcaKQ5zRbLVYXCIBMhkdDKRoFMACajPA4zCmnVa9O5sQn9YAzIhQEkTMTxDAsMFAgBKqL4dBIAB5aAwiIxfHJkMoWo0gA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1tiacTJTIAhtEK0yHJgBNK%2BSpPRRE0aB2iRwYAL4gtQA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3QAacDUhFYAVSLQ%2Bg9ABMAkkVXoAHmoCC0aOhLCwAMwCGqEuikBfEPaA&tokens=false

Can you confirm it's related ?

Will this mean that this issue will "fix itself" once the TS PR changes are released in a version of TypeScript (eg. maybe 5.2)?

Running with 5.3-beta now seems to still trigger the warning for me, so I'm assuming some fix is also needed here?