Using bit.dev components in a react app makes the webpack dev server very slow to start

[ashwanth1109]

Hi,

We are using bit to create components and pages for our app in a bit repository. We currently have a bunch of pages which are assembled in bit (with components also used from bit). So, the most complex page has dependencies that are 4 levels deep.
Adding all pages and components, we currently have a total of 30-40 components.

We have an app (bootstrapped from create-react-app) and we are using plain npm imports to import in components from our bit repo. The app has its own router, translation provider etc. and is responsible for fetching data and renders the page components taken from the bit repo. The app is started with the command:

export NODE_OPTIONS=--max_old_space_size=8192 && npm start

We had increased memory to 8192 because the dev server otherwise runs out of memory and also takes a very long time.
However, as we continue to keep building more components, we find that the time it takes to start the server, even at 8gb of memory is increasing. For example, it was taking a minute earlier, but after a new release of ours, its taking 3 mins.

Given that the number of components we have is not yet close to the final number of components we plan to ship via bit, this increasing memory consumption will be an issue for us if we continue down this path.

Can you kindly help me in understanding what could be the cause for this increasing memory consumption? How do we go about debugging this issue or gathering more information? Even a partial answer to the question (or just a starting point for where to look) would be very helpful and much appreciated. Thanks in advance!

[GiladShoham]

Hi,
I'm now actively working on the webpack memory consumption inside of bit.
But since you are using if I understand you correctly CRA webpack, and not bit one, it might be a different issue.
In your case, you only use the dist files created by bit.
So my best guess is that it's a result of bit compiling to CJS by default at the moment.
This means it makes webpack life harder doing tree shaking, which results in more files in the bundle, which results in more memory consumption.
I'm also actively working on changing our react env to compile to ESM by default, but I have some more work to do to complete it.
You can have a look at the PR.
Before changing the default, I'm going to give an easy API to change custom env to be an ESM.

If you don't want to wait for me to complete it, you can do it yourself right now (if you already have custom env it shouldn't be too much of work - about 10 lines of code).
basically, you need to override the tsconfig and set it to ESM.
We have our own custom react env which already does this (among other things), that you can use as a reference.
see it here - https://bit.cloud/teambit/community/envs/community-react/~code/community-react.main.runtime.ts
you should care about these lines

 react.useTypescript({
        devConfig: [transformTsConfig],
        buildConfig: [transformTsConfig],
      }),

once you have your own custom react with ESM, run bit compile and bit build and make sure you dist files are compiled to ESM (you should see import statements instead of require.
then you can try tagging all of your components again (it's recommended to tag the entire tree and not only the edge components), and install new versions of them in your CRA.

I'm not 100% sure this will resolve the issue, but it's my best guess at the moment.
You can of course also try to debug webpack memory consumption using memory dump tools, but explaining this is out of the scope I can explain in this discussion.

If you do find that moving to ESM is helping in your case, an update about it will be very valuable to us.
Thanks.