Loader? issue with 2.14+ and MUI 5 alpha

[eoliphan]

Hi, I'm running into a peculiar issue that I thought had something to do with MUI, but seems to only show up for shadow 2.14+. It's pretty simple to reproduce, with material-ui@next installed, just pulling in the @material-ui/core/Button class results in a chain of loads that blow up with "_styledEngine.keyframes is not a function" that corresponds to this line in the MUI source: https://github.com/mui-org/material-ui/blob/cf9bd04418b9ae41361c433481a7234caea37524/packages/material-ui/src/ButtonBase/TouchRipple.js#L36

It's super-weird because it's called twice prior to that.

Also, pulling in other components that use it (Skeleton, CircularProgress), may generate similar errors or complain that _styledEngine has already been defined. Backing down to 2.13.0 fixes it, so not sure if it's an issue with the latest closure compiler or something.

[thheller]

A reproducible repo would help.

2.13 -> 2.14 pretty much only had version updates on some dependencies and CLJS itself.

[thheller]

Just did a quick test and this appears to work fine on my machine with 2.14.3.

@next are alpha-level packages and this one in particular has a lot of peerDependencies. I suspect that you just have some older incompatible version of one of those packages installed.

AFAICT this is not related to shadow-cljs and rather just some dependency conflict. Closing due to that.

[MrEbbinghaus]

@eoliphan Did you ever found the solution? I have the same problem with the beta.0. :-/

[caleb]

I am running into this as well, but I'm on the latest Material UI v5 and I have to bump my shadow-cljs back to 2.12 before it works.

I've tried everything, including reducing my app to a minimal set of components and upgrading all of my dependencies. I also deleted my cache folders.

The thing that worked was downgrading my shadow-cljs to 2.12.0.

Any ideas?

[thheller]

:js-options {:entry-keys ["module" "browser" "main"]} in your build config might fix it.

[MrEbbinghaus]

Can confirm this works. 👍🏻

[caleb]

I applied this option and it worked but then funcool/decimal broke. I don't know why changing the :entry-keys option to load modules first would break the funcool/decimal library since that library doesn't use any package.json file and bundles the decimal.js library with it.

I managed to fix this issue by forking the funcool/decimal library (here: https://github.com/caleb/decimal) and updating it to use decimal.js from NPM, and pulling in that library by the ES6 module rather than using the old school global Decimal variable.

My new deps.cljs:

{:npm-deps {"decimal.js" "10.3.1"}}

This solution worked, but do you understand why the entry-keys change would break an old school foreign libs-based javascript dependency?

Here is how that dependency is included in the funcool deps.cljs:

{:foreign-libs
 [{:file "_decimal.js/decimal.js"
   :file-min "_decimal.js/decimal.min.js"
   :provides ["decimal.extern.decimaljs"]}]
 :externs ["_decimal.js/externs.js"]}

[thheller]

@caleb shadow-cljs does not support using foreign-libs at all. So you actually end up with using the decimal.js npm package, which I guess ships ESM and CJS code and funcool/decimal expecting to use the CJS variant.

[caleb]

@thheller Thank you for the help. Understanding these issues will save me hours of work in the future.