Do a bundler run as part of the CI

[fryorcraken]

This is a feature request

Problem

js-waku depends on novel packages such as js-libp2p family of libraries but also cryptography related libraries.
These dependencies change fast and do have breaking changes.
While these library target both browser and NodeJS environment, the biggest users are NodeJS (Lodestar Eth node).
Hence, regressions that only impact the browser can and have been introduced in the past. The most impactful one being the introduction of a NodeJS API usage, that then requires a polyfill in the browser or react native environment.
Polyfills mean added configuration to the bundler for js-waku maintainers and users, it also increases the final size of the web app using js-waku.

Proposed Solutions

Run as part of the CI/tests, a bundling of the library with popular bundlers. The default config of the bundlers should be used to ensure minimum friction of js-waku users.
List of bundlers to consider (some items in this list might not be bundlers):

• webpack
• react-scripts
• Preact
• Vite
• Rollup
• esbuild
• parcel
• SvelteKit

Notes

Would be good to review best practice for TypeScript library. In my time-boxed search, I could not find anything promising. Yet, I believe I have seen this pattern in the past.

Most likely, we want to have some very simple applications using @waku/sdk as a test.

[mfw78]

Not sure if it fits in the "bundler" category, but there are cases where bundlers, such as vite have framework-specific plugins that may modify the bundling environment.

For example, the use case that I have is being able to use SvelteKit (automatically uses vite for bundling) to create a project using js-waku.

[weboko]

@mfw78 good point. I quickly checked and it seems that vite can be used for that task as well. Since it is a front-end tooling similar to webpack.

[weboko]

As for the description just putting it in my words.
What we want to do is to have a step in our pipeline that helps to make sure @waku/sdk is able to be built within some abstract web application (react, svelte, etc).

I think before making it a bounty let's agree on boundaries of what is bare coverage.
I would say that if a web app with @waku/sdk in it is able to be built with 1 - 3 most common web frameworks and 1 - 3 most common build tools then we are safe. I am leaning towards 1, to be honest, because I don't see anything specific to web frameworks or build tools and I'd like to have at least surface here as possible.

The thing is if we have such a pipeline step configured then we'll need to support it in the same fashion as js-waku-examples: updating versions, fixing bugs and problems.

[mfw78]

So long as this meets the requirements of ensuring: "I'm a developer building in XYZ framework and @waku/sdk just works" where XYZ is in the list of the aforementioned frameworks. I'm no bundler expert and have wasted many hours digging into the dependencies abyss. Making this accessible, and preserving it's accessibility is key.

[fryorcraken]

Well that's the thing.
Even if it works with webpack and React uses webpack it doesn't mean it works with React because of some way React configures webpack (eg react-script doesn't support cjs files).

If we do not want an explosion of pipelines then we can just add pipelines for web frameworks but not bundlers.

[weboko]

Then let me summarise:

• we want to check if js-waku is able to be build within a web framework X;
• success criteria if it is built without errors;

To me, it seems those bullet points are very similar to waku-org/bounties#2 and only if we will keep those light weight (like a button) and quickly run in pipelines (per release e.g) then this bounty would make sense.

An additional step could be a combination of #52 and those simple web apps with js-waku in them.

[danisharora099]

@weboko to create a react example, and the other framework examples can be setup as bounties.

[weboko]

Todo:

• simple React example
• pipeline step for releases

write bounty for other framework examples not needed as should be covered by waku-org/examples.waku.org#271

[mfw78]

An example, right now, using svelte with the latest version of js-waku, the development server runs waku, no problems. But, unfortunately, after building, it no longer works.

[fryorcraken]

An example, right now, using svelte with the latest version of js-waku, the development server runs waku, no problems. But, unfortunately, after building, it no longer works.

What's the error? did you open an issue? @helpisdev also mentioned an issue with latest version of @waku/sdk.

[mfw78]

Sorry for the delay in getting back to this one. Currently in the environment:

• "@sveltejs/kit": "^1.15.5",
• "@waku/interfaces": "^0.0.15",
• "@waku/sdk": "^0.0.16",

Using vite ^4.2.1 as the bundler. The application works fine in the dev mode (ie. pnpm run dev), however, after being built it fails with:

A repository for reproducing this error is available at https://github.com/rndlabs/pastebee.

[weboko]

hey @mfw78, strangely I have the app working with pnpm install and pnpm run dev.

Maybe worth trying if you didn't:

• reinstall pnpm or even npm;
• removing pnpm-lock and node_modules;
• using @waku/sdk of 0.0.18 version;