Closed bingomanatee closed 10 months ago
for reference - it seems like the babel bundler looks at the fn a(){...code...})()
construct and explodes it into ...code... ignoring the internal reference to the executor
@bingomanatee thanks for reaching out.
This is quite odd. The two code fragments should be 100% equivalent. Bundlers shouldn't really destroy recursive IIFEs like that as it will certainly cause linting/runtime errors. I've used this module with Vercel's next.js and didn't notice any issue. But if there's circumstances in which it does perhaps it should be brought up with them.
Do you have a reproduceable example of this breaking, on codesandbox or similar?
yes - I made a project using your library at http://52.37.173.85/ -- https://github.com/bingomanatee/workworkwork-next is the code repo. In order to process it properly I have to run
find .next/ -name '*.js' -exec sed -i -e 's/requestAnimationFrame(onFrame),f.ZP.update()/(function onFrame(){requestAnimationFrame(onFrame),f.ZP.update()})()/g' {} +;
find client/ -name '*.js' -exec sed -i -e 's/requestAnimationFrame(onFrame),f.ZP.update()/(function onFrame(){requestAnimationFrame(onFrame),f.ZP.update()})()/g' {} +;
as a shell script; apparently the vercel flavor of webpack (or whatever) interprets (fn(){....content})()
as a silly way of expressing ...content
and exposes it, obliterating the named function in which its presented.
clearly, it is quite possible to get Vercel to "fix this" -- however considering they are probably using a bundling system that might be present in other contexts, I'd suggest bundler-proofing your code here. If this occurs in one context, it may emerge in others, and the fix really doesn't have any downsides.
I created a very more stripped-down example on vercel: https://github.com/bingomanatee/covid-client-2022 I added the regex bash file to the build pipeline to get it to work.
for some reason the name "onFrame" is not persisted when compiled in Vercel; variable-referencing the "onFrame" function should fix this.