Optimization for conditionals returning the compared value directly

[rentalhost]

Describe the feature

Hello! I wanted to suggest an optimization for how SWC handles strict equality checks where the returned value matches the compared value.

Take the following example:

function example(value) {  
  if (value === undefined) {  
    return undefined;  
  }  

  if (someConditional()) {  
    return value;  
  }  

  return doSomething(value);  
}  

Currently, this is optimized into:

function example(value, returnSelf) {  
    return void 0 === value     // if (value === undefined)  
      ? void 0                  // { return undefined }  
      : someConditional()       // if (someConditional())  
        ? value                 // { return value }  
        : doSomething(value);   // return doSomething()  
}  

If value === undefined, we could instead return value directly (instead of the literal undefined). This preserves the same behavior but allows the optimizer to produce more compact code:

if (value === undefined) {  
  return value;  
}  

With this change, the optimizer could simplify the ternary logic to:

function example(value, returnSelf) {
    return void 0 === value || someConditional()  // if (value === undefined || someConditional())
      ? value                                     // { return value }
      : doSomething(value);                       // return doSomething()

This approach should work for any strict equality comparison (e.g., === true, numbers, strings, etc.), as long as the returned value matches the compared value.

Thanks for considering this optimization! 😊

Babel plugin or link to the feature description

No response

Additional context

• Playground: example;

[Austaras]

In mainline of swc submitted code would be transformed into

export function example(value) {
    if (void 0 !== value) return someConditional() ? value : doSomething(value);
}

which doesn't contain return void 0. It's most possibly be caused by #10201

[kdy1]

Yeah I also think that's the cause. I'll finish #10202 asap and publish a new version.
My plan was to avoid publishing until #10202 is done, but I needed to publish a new version for nodejs folks.