Fork me on GitHub
#shadow-cljs
<
2023-05-28
>
scknkkrer15:05:36

Hello fellas, I have a question: I try to develop a Ionic application with Clojurescript, when I try to optmize with advanced mode, it compiles, works (mostly) but @capacitor-google-mapslibrary doesn’t work properly. Do I need to do anything in order to cover this situation? I believe with a clean installation and application, it won’t work either.

p-himik16:05:25

What do you mean by "doesn't work properly"?

scknkkrer18:05:28

I couldn’t manage to create map with it. When I trace the problem, I face many tricks that I didn’t face in the JSX implementation. It literally behaves differently.

p-himik18:05:27

Are there any errors in the JS console? Can you create an MRE?

scknkkrer19:05:05

Yeap, I will share it when I’m available.

scknkkrer19:05:41

It appears directly inside the library.

p-himik16:05:34

Would appreciate some pointers on how to debug a bad release build that involves an NPM library. In particular, the library uses CJS and inside a file there's a bunch of const foo = require('foo')-like statements. In dev, everything works properly, as well as in a tiny project with barely anything but that library where I tried to reproduce the issue. But in a release build of a real large application, one of those calls to require returns a wrong module. Specific details in a thread.

1
1
p-himik16:05:04

The library in question in Sentry. The source file with lots of requires: https://github.com/getsentry/sentry-javascript/blob/develop/packages/utils/src/index.ts Its CJS version from the NPM distribution: https://unpkg.com/@sentry/[email protected]/cjs/index.js (No idea how export * from './logger'; in TS became Object.defineProperty(...) in CJS - maybe important.) Shadow-cljs compiles it to this (elided unimportant parts):

shadow$provide[33] = function(P, aa, wa, y) {
    Object.defineProperty(y, "__esModule", {
        value: !0
    });
    P = aa(2);
    wa = aa(4);
    const q = aa(3)
      , z = aa(1)
      , m = aa(12)
      , x = aa(0)
      , r = aa(5)
      [...];
    aa = aa(11);
    y.getDomElement = P.getDomElement;
    y.getLocationHref = P.getLocationHref;
    y.htmlTreeAsString = P.htmlTreeAsString;
    y.dsnFromString = wa.dsnFromString;
    y.dsnToString = wa.dsnToString;
    y.makeDsn = wa.makeDsn;
    y.SentryError = q.SentryError;
    y.GLOBAL_OBJ = z.GLOBAL_OBJ;
    [...]
    y.CONSOLE_LEVELS = r.CONSOLE_LEVELS;
    y.consoleSandbox = r.consoleSandbox;
    Object.defineProperty(y, "logger", {
        enumerable: !0,
        get: ()=>r.logger
    });
    [...]
}
The issue is that in run time, that r is actually what q is supposed to be, and vice versa:
=> q
{logger: {…}, CONSOLE_LEVELS: Array(7), __esModule: true, consoleSandbox: ƒ}
=> r
{__esModule: true, SentryError: ƒ}

p-himik16:05:54

Debugging a release build is somewhat fun. :) So far I found that shadow$provide[5] points to the module with SentryError and shadow$provide[3] points to the one with logger. And there are other places that require 5 and 3 that do it before the code above, and they get the result they expect. But here for some reason either r and q are swapped, or 5 and 3.

p-himik16:05:50

Snooped around in the sources of shadow-cljs and found :js-options {:minimize-require true}. Changing it to false in the config of the release build fixes the issue!

nice 1
p-himik17:05:18

Ah, bloody hell. Tried the latest master via :local/root instead of 2.23.3 - worked perfectly without :minimise-require false. Removed all the cache as a way to "rub my eyes in disbelief" - still worked. Rolled back to 2.23.3 - it kept on working. So seems like an unpleasant case of caching issues, I suppose.

🎊 1