Shouldn't this be part of the state as well?

In theory, it probably should. But to create the state we need the lastMentionedDangerousGlobalRefs, and to compute those, we need the nameCompressor. So that would be tricky to manipulate. It seems easier to manage if it is outside.

Right. So let's table that discussion until we're settled on how to collect the names we want to minify.

Since the compressor isn't incremental, could we model it's result as a return value (whether or not it's the same object is irrelevant for the interface).

Then the beginning of emit could look like this:

if (minify) {
  val (compressedNames, dangerousGlobalRefs) = NameCompressor.compress(moduleSet, logger)
  state = new State(dangerousGlobalRefs, Some(compressedNames))
} else if (state == null) {
  state = new State(dangerousGlobalRefs = Set.empty, compressedNames = None)
}

This would also ensure that the state = null after emission releases a maximum amount of memory.

Going along with this: The duplication of the logic in the NameCompressor and the rest of the Emitter still makes me quite uneasy (even with the usage validation, IMHO it is not very easy to verify that the counting logic is correct).

If we use a return type, we could return different implementations that track or do not track the exact count.

I realize you were concern about not being able to approximate, but IIUC the only place where we do this right now is for Apply to hijacked classes. But this seems to be easy to do correctly:

• isMaybeHijackedClass is already factored in a helper.
• We can use the uncachedGlobalKnowledge to determine this in the NameCompressor.
• Updating the global knowledge needs to be moved to emit from emitInternal but that does not seem to be an issue.

Right. So let's table that discussion until we're settled on how to collect the names we want to minify.

Looking at this: I'm wondering if we should make this an implicit parameter.

Basically the rule we want is:

• When called from ClassEmitter, always set to true.
• When called from FunctionEmitter, always set to false.
• Otherwise, forward.

This call site violates the forward rule, I assume simply to avoid syntactic bloat. An implicit could solve this and would also make the call sites in ClassEmitter and FunctionEmitter cleaner.

I think we should also have checksizes for the minifier. Otherwise I think just with this, our test coverage is a bit low.

Since the compressor isn't incremental, could we model it's result as a return value (whether or not it's the same object is irrelevant for the interface).

Then the beginning of emit could look like this:

if (minify) {
  val (compressedNames, dangerousGlobalRefs) = NameCompressor.compress(moduleSet, logger)
  state = new State(dangerousGlobalRefs, Some(compressedNames))
} else if (state == null) {
  state = new State(dangerousGlobalRefs = Set.empty, compressedNames = None)
}

This would also ensure that the state = null after emission releases a maximum amount of memory.

Have you compared this (performance-wise) with an approach where we create one or two new maps just mapping to the generated name?

I haven't compared performance. Now that we track usages, though, we need more mutability after NameCompressor.compress is done anyway, so I don't think that would make anything simpler at this point.

Have you considered making this the natural order of PropertyNameEntry? Then, allocatePropertyNames could look like this:

val comparator: Comparator[PropertyNameEntry] = {
  Comparator.comparingInt(_.occurrences).reversed()
    .andThen(Comparator.naturalOrder()))
}

java.util.Arrays.sort(orderedEntries, comparator)

IMO this improves readability, since it keeps the (relevant) ordering condition more local. (FWIW, it might have a performance impact, IDK).

Rather than having a var for this, make a factory/helper method? This will make it more explicit, that it is only created once and never modified again.

Drop a comment about how collisions on computed names are accepted (in JS minifiers in general)?

Expanded the comment on the declaration of propertyNamesToAvoid.

Going along with this: The duplication of the logic in the NameCompressor and the rest of the Emitter still makes me quite uneasy (even with the usage validation, IMHO it is not very easy to verify that the counting logic is correct).

If we use a return type, we could return different implementations that track or do not track the exact count.

I realize you were concern about not being able to approximate, but IIUC the only place where we do this right now is for Apply to hijacked classes. But this seems to be easy to do correctly:

• isMaybeHijackedClass is already factored in a helper.
• We can use the uncachedGlobalKnowledge to determine this in the NameCompressor.
• Updating the global knowledge needs to be moved to emit from emitInternal but that does not seem to be an issue.

This is probably OK (given the amount of boilerplate otherwise), but I recommend this read:
https://testing.googleblog.com/2014/07/testing-on-toilet-dont-put-logic-in.html

I generally agree with not to put logic in tests, but here it was not reasonably possible.

This is compensated by the fact that the logic in the test should be as declarative as it gets, whereas the logic in the implementation is as imperative as it gets. The algorithms used are very different, so if they agree on the results, it's a good indicator that they're correct.

If we decide to keep the "usage only" check with this high amount of mutability, we might want to re-use _occurrences to store usage (set it to 0 when used).