I ran the test and it passes. 👍

Just skimming the code changes, it looks like this might be too narrow a fix; is this case handled?

if (condition) {
  localFunction();
}

@rhendric Such cases are indeed not handled. I think rather than trying extend this more and more into a full-fledged JS dead code analysis tool, we should set a boundary regarding what we support on FFI files. @hdgarrood put this better than I could in #4039 (comment).

To be honest, I even was on the fence regarding adding support for top-level function calls, but I guess they are useful for global polyfills (as in the case of purescript-contrib/purescript-arraybuffer#34). Do you think it is essential to support conditionals as well?

I think what's essential is that FFI files either work (possibly with unused code in the result, which a more advanced bundler might have eliminated) or fail at compile time (such as when a JS feature is not supported by our parser). That was the motivation behind my support of #4044, and it's why I'd rather support arbitrary statements at the top level in this fix. I could be convinced that throwing a compile-time error if such statements are encountered is the right thing to do instead (in which case this is a breaking change). But I wouldn't expect adding support for those statements to be difficult; we already have the ability to analyze arbitrary statements for their dependencies.

@rhendric What do you think is the best way to proceed with this? Should I add every possible JSStatement case under matchMember, similar to what I did with JSMethodCall? JSStatement has 35 data constructors, so I am not sure if that is the right thing to do, but couldn't come with anything better either.

I haven't tried it so I can't be sure it would work, but I probably would have started by leaving matchMember alone and instead adding a list of dependencies to the Other constructor, populating it in withDeps the same way that dependencies are populated for Members, and then changing compile to include any dependencies in Others in the list of entryPointVertices.

Superseded by #4255, much as plans to give a drab hallway a beautiful new coat of paint are superseded by the demolition of the building.

(Thank you for working on this anyway; hopefully this is not too frustrating an outcome for you!)