Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-07-11

Channels

#shadow-cljs
<
2023-07-11
>
hifumi12304:07:29

Is it possible to shim CLJS namespaces with goog.exportSymbol? I have a library that works with refx.alpha despite the fact the library uses re-frame.core

thheller05:07:35

please ask that question again without the goog.exportSymbol part. what do you want to achieve? redirect all calls from re-frame.core to refx.alpha?

thheller05:07:32

goog.exportSymbol is about exporting, i.e. preserving after :advanced. it is very unlikely to be useful for anything you want to do

hifumi12307:07:03

>redirect all calls from re-frame.core to refx.alpha? that is correct

thheller11:07:38

there is :build-options {:ns-aliases {re-frame.core refx.alpha}}, basically replaces every require and use of re-frame.core with refx.alpha

Hendrik08:07:44

How do I translate the following js into clojurescript with shadow? import { OrbitControls } from 'three/addons/controls/OrbitControls.js';

hifumi12308:07:07

I would guess (require '["three/addons/controls/OrbitControls" :refer [OrbitControls]), assuming the package does not use exports in its package.json (otherwise you will need to look at its exports and see what the “proper” path is)

👍 2
Hendrik09:07:14

That is what I expected to work. It turned out that three docs are incorrect: The correct import is: [“three/examples/jsm/controls/OrbitControls” :refer [OrbitControls]] https://stackoverflow.com/a/76267637/7483073

👀 2
hifumi12309:07:09

wow, good catch

orestis16:07:34

Here I am with another obscure use case. I'm trying to load Shadow-compiled CLJS code into a not-so-friendly environment: a legacy JS application which probably has polluted the global namespace. Esp. by using require.js. The error I'm seeing is: 

base.js?cache=bust:1279 TypeError: global.__exportStar is not a function
    at shadow$provide.module$node_modules$$sentry$utils$dist$index (index.js:4:9)
    at shadow.js.jsRequire (js.js:66:18)
    at shadow$provide.module$node_modules$$sentry$hub$dist$scope (scope.js:4:15)
    at shadow.js.jsRequire (js.js:66:18)
    at shadow$provide.module$node_modules$$sentry$hub$dist$index (index.js:3:15)
    at shadow.js.jsRequire (js.js:66:18)
    at shadow$provide.module$node_modules$$sentry$minimal$dist$index (index.js:4:13)
    at shadow.js.jsRequire (js.js:66:18)
    at shadow$provide.module$node_modules$$sentry$core$dist$index (index.js:3:17)
    at shadow.js.jsRequire (js.js:66:18)
where the index.js is something like that: 
shadow$provide["module$node_modules$$sentry$utils$dist$index"] = function(global,require,module,exports) {
Object.defineProperty(exports, "__esModule", { value: true });
var tslib_1 = require("tslib");
tslib_1.__exportStar(require("./async"), exports);

thheller16:07:35

no clue. this all looks like it should. what is the tslib related code in particular? seems like that is the source of the problem? maybe its a version conflict? some old/new incompatible tslib with a function missing?

thheller16:07:20

the source of the problem appears to be tslib, so not the the sentry code

thheller16:07:47

check if there is any reference to __exportStar or __assign in the tslib code

thheller16:07:15

I'd suspect that this is just a version conflict, using an incompatible version. i.e. not the tslib version sentry expects

orestis16:07:54

But I’m curious as to why this manifests in this legacy environment and not the standalone one. Perhaps since we use sentry also there there could be a conflict, as you say.

orestis16:07:37

I will try to sync the sentry versions and see what happens

orestis17:07:09

Turns out that we don't use sentry in development, so if it's a tslib incompatibility, it's something else causing it.

orestis18:07:27

I managed to load our base module if I set window.define to undefined (which is a require.js thing). However, loading an additional module doesn't work - I think require.js mangles things too much. Moving the code loading before require.js kicks in works but is more invasive.

orestis16:07:45

Another error is: 

base.js?cache=bust:1279 TypeError: tslib.__assign is not a function
    at shadow$provide.module$node_modules$downshift$dist$downshift_cjs (downshift.cjs.js:2347:43)
with the line in question being: 
var defaultProps$2 = tslib.__assign(tslib.__assign({}, defaultProps$3), { getA11yStatusMessage: getA11yStatusMessage });

orestis16:07:23

Note: the exact same code works fine outside of this environment, so I'm just looking to pointers to see if I can work around this somehow. The shadow version is 2.24.1.