I used eval as a workaround; autoexport does fs.readFile() on module’s filename and adds all lines marked with @export comment to exports. Eval is the only way to get a function value from other module, since functions are local to the context that is implicit and only accessible through eval-ing closure. That’s my code and my company, so I don’t push it to anyone now or in the future. I know how important antipatterns are in general.
Destructuring looks good here, you’re right. Actually, this thread somewhat relaxed my js hostility and I see it as an alternative that has reasonable tradeoffs (but still not as a friend though).
I have trouble picturing what advantage that setup would give over using ESM or node modules.
The Function constructor is a better alternative for eval(), but still only as a last resort. eval() itself has no use cases.
I find that most JS criticism is ill-informed, because people are too quick to jump to blaming the language due to its reputation. Not that I'd call JS a great language, but it has redeeming aspects.
Destructuring would make your example look better: foo({ui, commit, objs}), and then there's no need for typing out ctx. Another thing that's not needed with for-of loops is .iterate().
Using eval() is a very strong anti-pattern, and it's not needed there anyway. JS has the `with` statement that allows running code with a specific context, but its use is discouraged as it's really bad for readability and hard to optimize.