This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-03-02
Channels
- # beginners (7)
- # calva (10)
- # cider (9)
- # cljdoc (2)
- # cljsrn (10)
- # clojure (35)
- # clojure-europe (1)
- # clojure-greece (1)
- # clojure-spec (31)
- # clojure-uk (6)
- # clojurescript (3)
- # community-development (2)
- # cursive (37)
- # duct (5)
- # emacs (7)
- # fulcro (40)
- # hoplon (7)
- # off-topic (8)
- # parinfer (1)
- # quil (6)
- # re-frame (7)
- # reagent (7)
- # shadow-cljs (45)
- # sql (17)
- # tools-deps (12)
- # yada (3)
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?
hmm indeed. can reproduce. new directories just aren't picked up. wonder why this wasn't reported before
ok. indeed a bug that probably only happens on windows/linux. will need to verify for macOS
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.
hmm yeah I don't use re-frame so the .subs
.views
nested namespaces aren't that common for me
but I do create new packages sometimes. guess that always coincided with a restart or so
@arne-clojurians should be fixed in [email protected]
@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?
@U05224H0W I do - what’s up?
But I think I might not have been using it before
wait, no, we don’t set :language-out
I don’t think?
we set :feature-set :es5
so what I noticed is that GCC defaults to using strict mode, ie. it will emit "use strict";
in front of each module
that has certain implications for cross module code so that one module can't always see code from the other
:language-out :ecmascript5
does adjust the feature set but it also disables strict mode
I'll add that back as the default since it actually does more than just configure the :output-feature-set
which I previously assumed
maybe just setting :compiler-options {:language-out :ecmascript5}
solves your problem
but since you tried :output-wrapper true
the :language-out
probably won't actually fix your problem since :output-wrapper
works with strict mode
Interesting article on why no webpack
https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-not-webpack.html
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 🙂
kinda unfair though since shadow-cljs
was kinda built for exactly the scenario I setup 😉
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
further digging, if I call lazy/load
on the loadable, I get the error “Unknown module: app”
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.
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
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
wait, no, we don’t set :language-out
I don’t think?
we set :feature-set :es5