minifier: Inline variables where only used once

[overlookmotel]

Source (some code in oxlint):

for (let i = typeIds.length - 1; i >= 0; i--) {
  const typeId = typeIds[i];
  const enterExit = compiledVisitor[typeId];
  enterExit.enter = mergeVisitFns(enterExit.enter);
}

Minified:

for (let e = typeIds.length - 1; e >= 0; e--) {
  let t = typeIds[e], n = compiledVisitor[t];
  n.enter = mergeVisitFns(n.enter);
}

The t variable is unnecessary. It's only used once, and control flow is straightforward. Minified output could be:

for (let e = typeIds.length - 1; e >= 0; e--) {
  let n = compiledVisitor[typeIds[e]];
  n.enter = mergeVisitFns(n.enter);
}

Playground

[overlookmotel]

As a 2nd optimization, declaration of n could be hoisted into the for initializer, to remove the { + } braces and let keyword:

for (let e = typeIds.length - 1, n; e >= 0; e--)
  n = compiledVisitor[typeIds[e]],
  n.enter = mergeVisitFns(n.enter);

Or even remove n entirely, since e is not used again:

for (let e = typeIds.length - 1; e >= 0; e--)
  e = compiledVisitor[typeIds[e]],
  e.enter = mergeVisitFns(e.enter);

[sapphi-red]

The t variable is unnecessary. It's only used once, and control flow is straightforward. Minified output could be:

for (let e = typeIds.length - 1; e >= 0; e--) {
  let n = compiledVisitor[typeIds[e]];
  n.enter = mergeVisitFns(n.enter);
}

This case is difficult because the getter of typeIds may change compiledVisitor.

// before
let compiledVisitor = [0]
const typeIds = { length: 1, get 0() { compiledVisitor = [1]; return 0 } }
for (let e = typeIds.length - 1; e >= 0; e--) {
  let t = typeIds[e], n = compiledVisitor[t];
  console.log(n) // outputs "1"
}

// after
let compiledVisitor = [0]
const typeIds = { length: 1, get 0() { compiledVisitor = [1]; return 0 } }
for (let e = typeIds.length - 1; e >= 0; e--) {
  let n = compiledVisitor[typeIds[e]];
  console.log(n) // outputs "0"
}

To improve this, we need to detect whether the property access to typeIds changes compiledVisitor or not. That is really difficult, so I think the feasible way would be to detect whether the property access has a side effect.

For reference, this is the place where the transform for the case above is prevented.

oxc/crates/oxc_minifier/src/peephole/minimize_statements.rs

Lines 1717 to 1735 in 6fcb0d0

	// If both the replacement and this expression have no observable side
	// effects, then we can reorder the replacement past this expression
	//
	// ```js
	// // Substitution is ok
	// let replacement = 123;
	// return x + replacement;
	//
	// // Substitution is not ok because "fn()" may change "x"
	// let replacement = fn();
	// return x + replacement;
	//
	// // Substitution is not ok because "x == x" may change "x" due to "valueOf()" evaluation
	// let replacement = [x];
	// return (x == x) + replacement;
	// ```
	if !replacement_has_side_effect && !target_expr.may_have_side_effects(ctx) {
	return None;
	}

[overlookmotel]

Ah! I had not considered getters. It's much more complicated than I thought.

[overlookmotel]

If in the original code compiledVisitor is a const:

const compiledVisitor = [{ enter: null }];

for (let i = typeIds.length - 1; i >= 0; i--) {
  const typeId = typeIds[i];
  const enterExit = compiledVisitor[typeId];
  enterExit.enter = mergeVisitFns(enterExit.enter);
}

...then I think that's enough to know the optimization is safe. It doesn't matter if a getter on typeIds may mutate compiledVisitor, only that it doesn't replace it with a new value.

Ditto if compiledVisitor is a let or var, but the symbol has no assignments to it anywhere in the file (this still stands if the binding is export-ed from the file, because another file can only mutate the value, not reassign it).

I don't understand minifier enough to know if that's the principle that #13959 applies or not.

---

Note: Your example above had a typo. I've corrected it - hope you don't mind.

[sapphi-red]

Ah, that would work. Made #14184

[sapphi-red]

#14184