ngx-charts: 19.1 triggers angular import warning: swimlane-ngx-charts.js depends on 'clone-deep'. CommonJS or AMD dependencies can cause optimization bailouts.

I now get a warning for rfdc: @swimlane/ngx-charts/fesm2020/swimlane-ngx-charts.mjs depends on ‘rfdc’. CommonJS or AMD dependencies can cause optimization bailouts.

The clone-deep package is only used in one spot where is it completely unnecessary. It looks like clone-deep was not even added as a dependency. It is in node_modules only because of:

Hoisted from “@angular-devkit#build-angular#webpack-merge#clone-deep”

The warning should not be ignored, the usage should be removed.

This should be a priority fix. This was built for Angular, and this issue was opened 7 months ago.

Agreed - usage should be removed if at all possible

This should be fixed by now. This package has been built with angular in mind, but doesn’t respect angular requirement. Using CommonJS or AMD dependencies will result in optimization bailouts which cause the application to be slower. This should be a priority fix.

Add clone-deep to angular.json in allowedCommonJsDependencies

I updated to Angular 16 and still get @swimlane\ngx-charts\fesm2020\swimlane-ngx-charts.mjs depends on ‘rfdc’. CommonJS or AMD dependencies can cause optimization bailouts, warning.

I think this issue should be locked. I don’t think there is much else to add.

If anyone is looking to hide the message they can simply look back through the previous comments.

Anyone waiting for a fix can simply subscribe to this issue and wait for the status to change.

@hdkcreative This is not a work around, it’s just hiding the problem from the console so you forget all about it. I’d leave the message and wait for a fix

I do also get the warning on rfdc now. Is there any fix for this yet?

Facing similar issue in our project

There’s a new pull request that fixes this issue #1763 It corrects the underlying issue, and passes the build tests.

I proposed a fix by writing a custom function to clone the data, #1763. or you can use the lodash-es version in #1750

Either way, I don’t care how we fix it, this should be resolved by now. Can the maintainers choose a fix and just go with it? cloneDeep is only used in a single place, and even there the usage isn’t really about cloning something. Seems like people just want immutable data, and are going about it in the easiest way at the time.

Ok, I believe I found a solution to my issue. My warning says swimlane-ngx-charts.mjs depends on ‘rfdc’. rfdc only contains 2 functions; rfdc (opts) and rfdcCircles (opts). So, what I did is, I copied both functions into swimlane-ngx-charts.mjs and removed the line that imports that reference (import rfdc from 'rfdc’😉. This fixed the issue for me, as I’m not allowing CommonJS dependencies and the warning is gone. P.S. I only made that change on the fesm2015. The file in fesm2020 did not thrown any warning for me.

@hdkcreative This is not a work around, it’s just hiding the problem from the console so you forget all about it. I’d leave the message and wait for a fix

we decided to stop using that library!

What did you use as replacement?

hi, sorry for answering so late . . .

we are using https://primeng.org/ and https://developers.google.com/chart?hl=es-419

I updated to Angular 16 and still get @swimlane\ngx-charts\fesm2020\swimlane-ngx-charts.mjs depends on ‘rfdc’. CommonJS or AMD dependencies can cause optimization bailouts, warning.

Hi @StevenGee3398 can you evaluate and test this workaround :

“build”: { “builder”: “@angular-devkit/build-angular:browser”, “options”: { “allowedCommonJsDependencies”: [“rfdc”],

Same here as @cristopher55, I’m having this warning. Is there anyone working on a fix for this?

@marjan-georgiev any chance you could look at this? Do you need help maintaining?

Please can the maintainers provide some feedback on this? Like @bryanrideshark, I agree that either proposed solution would be fine, although I feel like @bryanrideshark solution is cleaner, as long as we can resolve this 👏

The warning should not be ignored, the usage should be removed.

I completely agree, suppressing warnings is not a solution.