@thheller good morning. the problem I described yesterday happens in the browser

if I print (prn (.-moduleInfoMap (loader/getModuleManager))) I get an empty map.

but I think it should contain the module information

that depends on where you print it. why are you printing it?

shadow$loader should only be assigned once? do you see it reassigned again in the code somewhere?

well, just before I load a module with (loader/load "my-module" callback)

this call fails with the following exception:

and what is the problem you are looking into again?

I'm trying to get my modules working again under advances optimizations. it used to work, but doesn't anymore with shadow 2.8.2.

when I look at my main module I see this in the beginning:

hmm I never used that form. can you quickly try (-> (loader/load "my-module") (.then callback))?

I suspect that the execOnLoad maybe was changed in the new closure lib (lots changed there)

and in the middle of the main module there's other javascript that looks like this:

which I think wipes out the module information.

yes, I'll try the promise version

hmm thats odd

but I think it will have the same problem

it may just be closure re-using the variable though

it does weird optimizations like that

the 2nd snippet I showed is the actual shadow.loader code, I think

which uses the same namespace as the module info

I really don't get why it is reassigned for you. I can't find any second assign in my code

hmm, strange

so at which point in your code is the shadow.loader namespace emitted

are you using pseudo-names to look at the js?

at the top as it should be

both. tried with and without pseudo-names

and the module info comes after that?

var shadow$loader = {"uris":{"demo":["/js/demo.js"],"extra":["/js/extra.js"]},"infos":{"demo":[],"extra":["demo"]}};

from the code I pasted above I don't understand how this can work. in the generated code I have, either the module info will wipe out the shadow.loader namespace or the other way around

yes but I don't get where your second shadow$loader assignment is coming from

that doesn't make sense to me

if the shadow.loader code gets evaluated first, you might be lucky and the definitions are in the runtime by the time the module info wipes out the namespace

I think it's the shadow.loader namespace

;var $shadow$loader$ml$$ = new $goog$module$ModuleLoader$$;
$shadow$loader$ml$$.$sourceUrlInjection_$ = !0;
var $shadow$loader$mm$$;
!$module$contents$goog$loader$activeModuleManager_moduleManager$$ && $module$contents$goog$loader$activeModuleManager_getDefault$$ && ($module$contents$goog$loader$activeModuleManager_moduleManager$$ = $module$contents$goog$loader$activeModuleManager_getDefault$$());
$shadow$loader$mm$$ = $module$contents$goog$loader$activeModuleManager_moduleManager$$;
$shadow$loader$mm$$.$loader_$ = $shadow$loader$ml$$;

I'm just experience the case that the shadow.loader namespace gets emitted AFTER the module info. in your case it seems to be the other way around

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/loader.js

what do you mean? do you not have var shadow$loader = ... assignment at the very top of the file?

var shadow$provide = {};
if(typeof Math.imul == "undefined" || (Math.imul(0xffffffff,5) == 0)) {
    Math.imul = function (a, b) {
        var ah  = (a >>> 16) & 0xffff;
        var al = a & 0xffff;
        var bh  = (b >>> 16) & 0xffff;
        var bl = b & 0xffff;
        // the shift by 0 fixes the sign on the high part
        // the final |0 converts the unsigned value into a signed value
        return ((al * bl) + (((ah * bl + al * bh) << 16) >>> 0)|0);
    }
}

var shadow$loader = {"uris":{"demo":["/js/demo.js"],"extra":["/js/extra.js"]},"infos":{"demo":[],"extra":["demo"]}};

like that?

that should be the absolutely only assignment ever

yes, I have that. but in the same file the shadow.loader code is emitted after this module info declaration

the code that translates the shadow$loader into the actual runtime data is coming way later

that is normal yes

which I think wipes the module info out

please stop for a second

lets clean up our understanding of the situation

a) your COMPILED code contains two assigns for shadow$loader?

does matter where

ie if you grep your compiled code for shadow$loader = that should only find ONE occurence

oh fuck .. I have a guess

do you have :module-loader true in your build config?

yes, I have :module-loader true.

hmm doh

I think I tried without, but let me check again

no it should be in there

but again please answer my question

how many assignments are there?

2

the correct one at the top and the empty one later?

but, let's clarify this also. shadow$loader is getting assigned 2 things. the module info and the shadow.loader namespace, right?

so this file: https://github.com/thheller/shadow-cljs/blob/01a0b4810047c719ae528f5ff2bdd26b0dcfe4fd/src/main/shadow/loader.js

ok I reproduced the problem now

and the module info which is then used by the shadow.loader namespace

if I remove :module-loader true from my config it breaks like yours

I guess I messed up the automatic detection of that flag

it is supposed to be detected automatically so you don't have to set it

please check if you have :module-loader true in your config in the correct place

:module-loader true :modules {...}

just right above :modules, yes

hmm typo?

no, it's fine

I can definitely reproduce it when it is not set but adding it fixes everything

well. I'll fix it so you don't need to ever set it

Hi @thheller I am trying to add a ~/.b42 into the classpath in shadow-cljs.edn :source-paths but i think it doesnt resolve ~as home directory.

Hi, I’m getting [:did-not-find <name-of-ns>] errors for namespaces that do exist. What does this error indicate?

@metacritical yes it doesn't resolve source paths at all. I wouldn't expect that to work in any java setup?

@jlmr that happens in your (in-ns 'foo.bar) without having done (require 'foo.bar) first

Ok, thanks, will look at it further

For some reason the errors are not occuring now 🙂

https://github.com/thheller/shadow-cljs/issues/398

@thheller Thanks!

So, I'm getting this reference error when importing this js lib, and I see that is seems to be looking for an underscored version of the library. is that relevant to the problem? ReferenceError: module$node_modules$aws_appsync$lib$index is not defined

seems to have sorted itself out, actually... I think it must have been outside the compile path for that build

@thheller I noticed something a bit weird, I have in my project my own cljsjs files for some libs that we do override impl, I noticed if I put a .js file in the cljsjs ns and try to require it, shadow can't find it, but moving to a different folder cljsjs-mine for example makes it work, seems like its doing special threatment for cljsjs, is that expected?

yes that is expected

otherwise it would start inspecting all the files in cljsjs which would include all the foreign libs

I'm probably removing the classpath indexing soon though since its not really all that useful

then I could lift that restriction

cool, thanks for the clarification