Review/refactor bundler setup

What is the problem?

We’re currently including 2 bundlers as dev dependencies, rollup and webpack.

It seems that storybook requires webpack. and that our project is using rollup. We should look into using one single bundler.

Why?

Having more than 1 bundler introduces unnecessary complexity. Bundlers are already complicated in nature to configure and debug, it’s something done early in a project and it’s hard to modify as the project increases in complexity. Having 2 bundlers could potentially increase that complexity further.

How?

Whoever picks up this issue should answer the questions:

• Which bundler will work for both the project and storybook?
• If there is more than one option, which one is the best one? Other options to look into Parcel, Snowpack.

Expected outcome

• One single bundler in the dev dependencies
• One single configuration in the root of the project
• Both storybook and the react project still compile without a problem

[etr2460]

A summary of conversations and research:

Webpack For Storybook to work, it needs a webpack config. So we’ll always have webpack in the repo, but it’ll only be used for Storybook, so should be pretty decoupled from the build process for releasing new packages.

Parcel and Snowpack also seem more in the vein of Webpack as being focused on applications, not libraries, so they don’t seem like the best fit.

Rollup The status quo for building for release, and seems to do everything we need right now. However, we seem to use very little of the features it supports, and the fact that it bundles all our TS into a single JS file seems less than ideal. One reason using rollup (or a more complex builder/bundler) could be valuable would be if we anticipate a large variety of files being needed beyond TS/TSX (css for example, or others)

tsc If all we have is TS/TSX files, then I think we can use the typescript compiler to build all the static assets we need. This would reduce the number of dependencies in the repo, but would require a bit more customization, and makes adding non TS/TSX files to the package a bit more tricky

babel Similar to tsc, we could use babel to transpile all the TS/TSX for the build, and also load a variety of other asset types as needed. Requires a bunch of configuration though, and might not be needed since anyone who uses our library could ensure that the code they output will work on their target.

preconstruct Is built for monorepos, but uses babel under the hood for build output (correct me if i’m wrong @with-heart, but according to their docs they rely on the babel config). Would require the configuration mentioned above for babel, plus a bit more to manage the monorepo and separate packages.

Recommendation

Since today all we have is TS/TSX files (and it looks like Chakra-UI uses CSS-in-JS), i think it’s feasible to build everything with tsc only. I’m not sure if this is 100% best practice (i’m a bit new to bundlers/builders) but it looks pretty clean to me today. Let me know if i’m missing anything here. It’s very possible that this could all change with the monorepo as well (considering i’m assuming we’ll want to publish/build packages independently), and maybe something like preconstruct will make more sense then. I’m also looking into lerna for monorepo management (have used it before), but it seems to be somewhat separate from building.

Proposed PR: https://github.com/Developer-DAO/web3-ui/pull/23

[etr2460]

Thanks @with-heart for more details on how Chakra uses preconstruct. Since we don’t quite have a monorepo here yet, would you recommend that:

• My PR migrate off rollup in favor of a basic babel + preconstruct setup
• The future monorepo PR then builds off this work to get building and publishing working for all sub packages