This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
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-maps
library 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.
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.
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.
The library in question in Sentry.
The source file with lots of require
s: 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: ƒ}
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
.
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!

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.