3

My monorepo looks as follows:

  • app1
  • packages/package1
  • packages/packageN

This is a yarn 3 monorepo with turborepo for caching build assets.

  • App1 consumes package1.
  • App1 is a simple Vite React app.
  • Package1 is a react component library. Also uses Vite and react.
  • TypeScript is used across the board.
  • I do not use babel directly anywhere.

On initial setup, app1 was directly consuming package1 without a build step in between. This seemed reasonable since they all live in the same monorepo. However, massive performance issues and hundreds of messages like these:

@app1: [BABEL] Note: The code generator has deoptimised the styling of ... as it exceeds the max of 500KB.
@app1: [BABEL] Note: The code generator has deoptimised the styling of ... as it exceeds the max of 500KB.
...
@app1: [BABEL] Note: The code generator has deoptimised the styling of ... as it exceeds the max of 500KB.

caused me to pick another route, which was to build package1 and consume it in app1. This did help, until now, where the same behavior described above is happening even with the built version of package1.

I'm unable to pinpoint the root cause of this. My closest assumption is Vite misconfiguration for a monorepo, but I haven't had much luck there when researching options.

What is the potential cause of app1 having performance issues in this setup and also outputting many of the warning above?

aborted
  • 4,481
  • 14
  • 69
  • 132
  • Would https://www.npmjs.com/package/madge help, by identifying any potential circular dependencies in your project? – VonC Aug 09 '23 at 20:17
  • I have not used this before. You suspect it could be circular deps? There are no occurrences of app1 being used in package1 if that's what you mean, only the other way around. – aborted Aug 09 '23 at 21:47
  • Do you mind to take a look at this answer https://stackoverflow.com/a/36880182/8689487? I know that this is quite old, but maybe it can help – Leandro Lima Aug 15 '23 at 16:16
  • Perhaps [this](https://stackoverflow.com/a/29857361/9894625) may help you – NoNam4 Aug 29 '23 at 13:30

1 Answers1

-2

The issue you're encountering, specifically the "The code generator has deoptimised the styling of ... as it exceeds the max of 500KB" warnings, is indicative of Babel having to deal with very large files. The 500KB limit is there to prevent performance issues; going beyond it will slow down Babel and likely your entire build process.

Given that you are using Vite, TypeScript, and a monorepo setup, the issue could be coming from multiple areas:

Monorepo Symlinks: When working in a monorepo, package links can sometimes make tools like Babel and Webpack behave differently, treating linked packages as if they are part of the main package. This could potentially lead to the bundling and transpiling of a lot more code than you'd expect.

Tree Shaking: If the package (or packages) being consumed are very large and not well-optimized for tree shaking, it can result in the importing of more code than is actually needed. This would also exacerbate the size limit issue.

Bundling Configuration: With Vite, make sure that the external dependencies are correctly marked and that internal packages are being properly optimized. Vite has its own way of handling common JS and ESM packages, which might conflict in a monorepo setting.

Shared Dependencies: In a monorepo, if dependencies are not properly hoisted or shared, it can sometimes lead to duplicate copies of the same code, thereby increasing the size of the bundled output.

Package Transpilation: If you've built package1 to target a much older version of JavaScript (like ES5), it could produce larger code, which, when consumed by app1, makes it exceed the size limit.

Some Solutions: Optimize Dependencies: Make sure that only the code that is actually being used is imported. This will make tree-shaking more effective.

Check the Build Output: Look at the build output to identify any unusually large files or dependencies. Try to understand why they are large and if they can be broken down or lazily loaded.

Vite and TypeScript Configurations: Make sure Vite and TypeScript are properly configured, especially with respect to how they resolve modules in a monorepo. Vite has a resolve.alias config option that can be helpful. Inspect Package1: The component library itself (package1) might need to be optimized. Look at ways to make it smaller or to divide it into smaller chunks.

Turborepo Caching: Make sure that Turborepo is correctly caching your build assets and not causing these large build sizes indirectly. Investigate Warnings: The warnings could potentially be silenced by increasing the compact option limit, but it's not recommended because the underlying performance issue would still remain.

DevGuy
  • 123
  • 1
  • 3
  • 10