-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPIKE: Simplify/clarify browser-based development #2733
Comments
I believe a separation between stacks is not necessary. The important aspect or separation here is between the bundler e.g. Webpack and Vite. But not 100% sure. I also think this would solve that issue #1528 The idea with having a |
I arrived here as well after 2 days of debugging polyfill issues. As a library that's targeted towards FE development primarily, it seems that it's a second priority. I'm using Astro at the moment which is using Vite under-the-hood for what it's worth. I'll take a look at the vite config that's been posted in order to get this working. |
The polyfill example in the react repo worked; thanks! Please add this somewhere on the site for other folks using Vite. |
What are the goals of the research?
Currently, simply adding the Taquito and Beacon packages to an app does not work. Developers need to polyfill the nodejs dependencies (like
stream
,util
,buffer
, etc) in the browser. This needs to be done before anything can be done. It would be great if there was a solution baked into Taquito, that users could simply use.Imagine if there was a
@taquito/browser
, and including it would polyfill these dependencies.If it's not possible to have one package for all frontend technologies, maybe having a separate one for important stacks, like
@taquito/browser-react
, and@taquito/browser-angular
, and@taquito/browser-svelte
could be the solution. However, that increases the number of packages we need to maintain.Alternatively, we can have per-stack documentation of how to do this.
Describe the concrete outcomes of the research below. Can include questions/areas that need to be investigated/discussed
Acceptance criteria:
It should be completely straightforward for developers to start developing dApps. Facing early problems can deter potential adopters.
The text was updated successfully, but these errors were encountered: