Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Review/refactor bundler setup

See original GitHub issue

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.


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.


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:closed
  • Created 2 years ago
  • Comments:7 (7 by maintainers)

github_iconTop GitHub Comments

etr2460commented, Nov 28, 2021

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.


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:

etr2460commented, Nov 28, 2021

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
Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found