Fork me on GitHub
#shadow-cljs
<
2019-03-02
>
heyarne09:03:21

I'm experiencing a bug and I'm not sure how to provide useful information on it. The situation goes like this: I start up shadow-cljs, my project compiles. I create a new folder, a new nested namespace... so theres airsonic-ui.components.*, where '*' means several different namespaces already existing. I create airsonic-ui.components.sortable.views, the namespace cannot be required. shadow-cljs warns me that it doesn't exist. I move airsonic-ui.components.sortable.views up to airsonic-ui.components.sortable, it's found. Any idea what might be going on here?

thheller09:03:52

hmm might be that new directories aren't watched properly automatically?

thheller09:03:11

which OS do you use?

thheller09:03:35

hmm indeed. can reproduce. new directories just aren't picked up. wonder why this wasn't reported before

thheller09:03:02

maybe it works properly on macOS since that uses a different watcher

heyarne09:03:17

Again: it's amazing how responsive you are in this channel. Thanks so much! 🙌🙌🙌

thheller10:03:30

ok. indeed a bug that probably only happens on windows/linux. will need to verify for macOS

thheller10:03:42

wonder why I never ran into this before 😛

thheller10:03:56

guess I don't create a new directories often enough 😛

heyarne10:03:01

It's actually a question that I ask myself often enough. I have a re-frame project and there are several components... some of them have their own events and subscriptions, some are only views. Do I always create main-namespace.comp.views or is main-namespace.comp enough? I guess it's a question of how defensive you write your code.

thheller10:03:01

hmm yeah I don't use re-frame so the .subs .views nested namespaces aren't that common for me

thheller10:03:36

but I do create new packages sometimes. guess that always coincided with a restart or so

heyarne10:03:02

Can confirm that it's working 🙂

heyarne10:03:17

This is amazing! Bug + fix in less than 30 minutes. Again, thanks!

thheller13:03:14

@anmonteiro wow I think I may have found the reason you were running into problem with :modules, well maybe. do you set :language-out in your config?

anmonteiro18:03:58

@U05224H0W I do - what’s up?

anmonteiro18:03:18

But I think I might not have been using it before

anmonteiro20:03:08

wait, no, we don’t set :language-out I don’t think?

thheller21:03:50

so what I noticed is that GCC defaults to using strict mode, ie. it will emit "use strict"; in front of each module

thheller21:03:13

that has certain implications for cross module code so that one module can't always see code from the other

thheller21:03:54

:language-out :ecmascript5 does adjust the feature set but it also disables strict mode

thheller21:03:28

I'll add that back as the default since it actually does more than just configure the :output-feature-set which I previously assumed

thheller21:03:03

maybe just setting :compiler-options {:language-out :ecmascript5} solves your problem

thheller21:03:00

but since you tried :output-wrapper true the :language-out probably won't actually fix your problem since :output-wrapper works with strict mode

thheller15:03:04

currently writing another post showing how to use :modules properly which will hopefully make it a bit clearer why the "double-bundle" appraoch using webpack is bad 🙂

thheller15:03:43

I kinda want to add a challenge: build this with CLJS but without shadow-cljs 😉

thheller15:03:23

kinda unfair though since shadow-cljs was kinda built for exactly the scenario I setup 😉

mhuebert18:03:19

hmm, getting this isLoaded error when i call lazy/loaded? here. i am printing + js/logging the loadable above, so it itself is not undefined

mhuebert18:03:46

further digging, if I call lazy/load on the loadable, I get the error “Unknown module: app”

mhuebert18:03:20

:app is definitely one of my modules

thheller20:03:51

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

thheller21:03:07

thats currently required

thheller21:03:00

the problem is likely cause when a module id is used that doesn't actually exist

thheller21:03:11

it won't exist if :module-loader true is not used

thheller21:03:16

otherwise it should be there

mhuebert22:03:16

Ah that would be the problem

mhuebert18:03:13

another issue, I have a bunch of code that is shared between browser + nodejs. the browser build uses module splitting, while the nodejs build doesn’t. I am getting “Could not find module…” errors when trying to compile the node app.

mhuebert19:03:57

I don’t use any of that stuff from node, i think it would be nice if there was just a runtime error if I ever tried to load one of the loadables

thheller20:03:33

good point. I'll see if I can think of something proper