Review/refactor bundler setup
See original GitHub issueWhat 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
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
How to use Bundler with Ruby
Setting Up Your Application to Use Bundler. Bundler makes sure that Ruby can find all of the gems in the Gemfile (and all...
Read more >Understanding Bundler's setup process - Brian Storti
It's the de facto solution for dependency management, and it's hard to find a project without a Gemfile . What is not part...
Read more >`require 'bundler/setup'` fails on 2.5.1 if bundler is located in ...
require 'bundler/setup' in any project with Gemfile.lock fails with various LoadError s. In empty project: $ mkdir testapp && cd testapp && ...
Read more >cannot load such file -- bundler/setup (LoadError)
In my case this error occurs after installing bundler v2. I resolve it with gem uninstall -a bundler; gem install bundler -v '<2.0'...
Read more >Investigate Review App Failures (#212) · Issues - GitLab
CPU usage on nodes are maxing out at 100% which indicates requests do not align with pod needs. This would also limit the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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 intolerna
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
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: