airgap-it / beacon-sdk

The beacon sdk allows developers of dApps and wallets on Tezos to implement the wallet interaction standard tzip-10.
https://walletbeacon.io
MIT License
101 stars 65 forks source link

TypeError: BeaconEvent is undefined in Vite v5 #668

Closed BearCooder closed 11 months ago

BearCooder commented 11 months ago

Describe the bug (current behavior) I have a working dapp. The setup I use is React with Vite v4 together with taquito and Beacon.

Now after I updated Vite to their latest release v5 I get always a blank page and the error in the browser console: TypeError: BeaconEvent is undefined. grafik

Now when I click to show me source it is something not working in the beacon package I guess: grafik

I cant even really fix it as I get no errors in my console in WSL when I start to run it locally. No errors, just a blank page appears and then a look in the browser console shows me this.

I use WSL with node v 20.9.0 and the latest taquito and beacon versions.

IsaccoSordo commented 11 months ago

Hi @BearCooder, thanks for your report. I don't know your specific vite setup, here I have created a simple beacon playground with vite 5 and react. Please tell me if you manage to also replicate your issue with the playground

BearCooder commented 11 months ago

Hello @IsaccoSordo thank you for the quick answer.

I can provide you the whole template that my project is based on. Here: https://github.com/dvkam/Tezos-Template

Please clone it and install dependencies and try to run, it will work. But when you delete node modules and just change the Vite version to v5 in package json and install again. Then you will get the problem I described. A blank page and in browser console the error from above..

Even when beacon and taquito is updated to the latest version with Vite v5 I get the same :(

IsaccoSordo commented 11 months ago

Hi @BearCooder, thanks for sharing your code. I see now, the problem is not vite per se but the fact that you most likely need to run npm i --lecacy-peer-deps or npm i -f Using those flags might introduce unintended consequences, as the flags allow for looser constraints on dependencies. In your specific case what you can do if you still want to use vite@5 is to change the import, inside Wallet.ts , from import { NetworkType } from "@airgap/beacon-sdk"; to import { NetworkType } from "@airgap/beacon-dapp"; Please let me know if this solves your issue.

BearCooder commented 11 months ago

Wow, changing the import from import { NetworkType } from "@airgap/beacon-sdk"; toimport { NetworkType } from "@airgap/beacon-dapp"; solved the issue! Thank you very much!

Can you please explain what the difference here is and why the old import worked fine in Vite v4 and now not anymore in Vite v5?

IsaccoSordo commented 11 months ago

I'm glad it worked out for you, I'm closing the issue. ~If you need more details about npm i --legacy-peer-deps I found this nice StackOverflow issue which explains it in details: what-does-npm-install-legacy-peer-deps-do~ EDIT: Read the comment below

BearCooder commented 11 months ago

Thank you @IsaccoSordo but one last question. I just changed the import and did not run npm i --lecacy-peer-deps. I read the linked Stackoverflow issue but I do not can find how this is connected with it? I just changed the import like you said, nothing else?

IsaccoSordo commented 6 months ago

Hi @BearCoder, I apologize for the significant delay in my response – I've been tied up with other duties. Regarding the issue you raised, I've been investigating it alongside my other tasks. It took some time, but I've identified the root cause. The issue appears to be with Vite’s TypeScript transpilation, specifically in how we bundle our submodules in Beacon. For instance, in beacon-dapp's index.ts, we export necessary submodules like beacon-core and beacon-types. However, this is also true for beacon-sdk, which exports the beacon-app submodule. It seems recent changes in Vite's transpilation process now create a circular dependency. If you want you can build Beacon locally by branching out from fix/clashing_types and you’ll see that the issue no longer appears. Although we might not proceed with merging PR#738, it's currently open for internal discussion. Thanks a lot for opening this issue.