This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-28
Channels
- # aleph (50)
- # announcements (3)
- # aws (35)
- # beginners (74)
- # boot (25)
- # calva (39)
- # cider (18)
- # clara (2)
- # cljdoc (18)
- # cljs-dev (24)
- # cljsrn (11)
- # clojure (166)
- # clojure-europe (13)
- # clojure-italy (5)
- # clojure-nl (6)
- # clojure-spec (35)
- # clojure-uk (263)
- # clojurescript (22)
- # clojutre (1)
- # code-reviews (34)
- # cursive (58)
- # data-science (2)
- # datascript (4)
- # datomic (4)
- # duct (6)
- # emacs (7)
- # figwheel-main (9)
- # fulcro (2)
- # graphql (3)
- # hoplon (22)
- # hyperfiddle (2)
- # juxt (5)
- # kaocha (6)
- # leiningen (33)
- # luminus (15)
- # off-topic (1)
- # pedestal (5)
- # reagent (18)
- # reitit (12)
- # shadow-cljs (171)
- # vim (5)
@thheller hey thomas, me again
We’ve pushed and reverted code splitting to prod about 3 times now
note that all I’m gonna say is very empirical, as I can’t get a clear repro
we’re seeing this weird issue where apparently everything seems to work on a merged commit, but whenever someone merges another commit to master and we deploy the bundles break in subtle, horrific ways
my current hypothesis is that symbols are not “stable” (?) across different compilation runs?
I certainly hope not
nope, what’s that?
checking the guide
also, could :fn-invoke-direct true
be weird here?
otherwise cache might get in your way in that a user may have an older version of a module cached and mix it with a module from another build
I don’t think we need that
Buck generates its own hash out of compilation and we have “immutable compilation artifacts”
to serve the bundle on the server side
the Buck SHA gets generated after compiling the assets
we use to SHA as the path to upload it to the CDN
we embed it in the HTML as transit
we read that from the JS, and call shadow.loader.init
no, I call shadow.loader.init
is there something I’m missing?
yeah!
to be precise: https://ddw3p1oh0ex89.cloudfront.net/assets/b/03703cffd7d3273643cddc57dbba4d0b1213d793/static/js/ladder/main.js
yeah..
note that my assumption could be wrong too
> my current hypothesis is that symbols are not “stable” (?) across different compilation runs?
yes that one
symbols are only "stable" between builds if you preserve the .shadow-cljs/builds/<your-build-id>/release
directory which you probably don't do
ok let me establish the symptom first
for code splitting we generate a thunk like you do in shadow.lazy
in fact your recent shadow.lazy
addition is very similar to what we do
which validated our approach somehow 😛
and what I think I’m seeing (again, I don’t get a clear repro so some things are very subjective) is that the symbol I embed in the thunk cant be found
so the symptom with "mixed" code would be that module-b
was compiled against module-a
where cljs.core.assoc
was named xT
. Another build however assigned xT
to cljs.core.conj
. Now the module-b
is suddenly calling cljs.core.conj
in places where it expects to call cljs.core.assoc
. Obviously breaking in horrific ways.
but all I get (for now) is undefined is not an object (evaluating 'M.h')
did you try compiling with shadow-cljs release your-build --pseudo-names
and check what that is?
I did try with pseudo-names
and couldn’t repro, or badly
I think I got 1 repro with pseudo-names
and it said cst$sym$...
doesn’t exist
something from the constants table
do you use cst$sym
names at all?
I saw cst$sym$$props__auto__NNN
for sure
or does the page include other global JS that may override symbols from the CLJS compilation?
do you use the :output-wrapper
? https://shadow-cljs.github.io/docs/UsersGuide.html#output-wrapper
should I be using :output-wrapper
explicitly?
I thought it was the default
@thheller so that would explain why I can’t repro in dev / staging
bc we have a bunch of external analytics scripts running in prod
that could certainly explain why we don’t see it sometimes
but then we see it in the next build
I’ll try that, thanks for help!
@thheller do you have a donation page for Shadow?
we’re putting aside some money for CIDER right now
could also set aside some budget to help out Shadow
Since you all keep asking I finally started setting up my Patreon: https://www.patreon.com/thheller
@thheller btw broken again with :output-wrapper
…..
I’m sure this is my own fault but I’ve been at it for so long that I’m running out of clues
@anmonteiro did you try source maps? does that provide any hint at all?
source maps are very confusing
and don’t indicate the right lines
maybe because of macros?
js->clj
where, for example?
like, what would it impact?
it mostly shows if you use js->clj
on JSON data that has short property names with numeric values. eg. {"x":4}
hello, quick question, I am trying to use shadow-cljs from a repl. When I use shadow.cljs.devtools.api/watch :a-build I get a “missing instance” error. From what I understand the exception comes from shadow.cljs.devtools.server.runtime/get-instance. Do I need to start something before using the watch fn?
@jeremys you need to start the embedded server first: https://shadow-cljs.github.io/docs/UsersGuide.html#embedded
hrm we do use js->clj
in some places, but I don’t think they’d be in this code path
@anmonteiro the problem shows in extremely weird ways. like showing errors on completely unrelated parts of the code that should not be called at all
@thheller that’s what I’m seeing
> showing errors on completely unrelated parts of the code that should not be called at all
but I can’t repro locally
even when serving the optimizd bundle
probably not
I spent days trying to debug this in the past until I finally figured out what was causing it and stopped using js->clj
for JSON data 😛
but you said you saw the issue with :pseudo-names
which probably rules this out since the issue can't really happen with that
just in case did you try running shadow-cljs check your-build
? It might provide a clue
can I just use cognitect.transit
to read JSON data?
@thheller is there a way to run check
as a library?
trying
can it be run in dev?
its not as useful as I'd like it to be since it reports too many false positives but something it can find hidden externs issues
673 warnings
let’s see
js.js:132 shadow-cljs - failed to load 59 how can I find out what module is number 59?
hmm actually that info isn't exported anywhere. you can set :js-options {:minimize-require false}
yes, it lists it in source maps, I get three "failed to load" messages with different numbers, but only one stacktrace
yup, it's lazy-cache module, npm ls lazy-cache
shows a prompt module that Im using, wondering if I should remove it...
ahhh ok, sorry totally my fault, for some reason, I'm loading a nodejs module, I have some code that I share between node and browser, and it didn't get DCE
yeah. I actually implemented removing unused JS requires but that had very bad consequences 😛
no. removed entirely. may come back in a different form at some point, maybe as a warning of sorts.
but I can avoid this by seperating the common code better. This release did work when I compiled in November with same namespaces that required the same modules.
I generally check if the build report is clean and doesn't contain stuff it shouldn't
it makes sense in my case that it's included, a bit, I'm requireing 2 functions from a namespace that requires the unwanted module, but these functions don't call the module.
feature request:
(defn get-manifest
[id]
(-> (shadow/get-build-config id)
:output-dir
(str "/manifest.edn")))
Or maybe return manifest from (shadow/release :id)
you can use (-> (shadow/get-build-config id) (shadow/release* {}) (extract-whatever-info-you-need))
release*
returns the full build state after compilation which contains everything the manifest contains?
in which case returning the build state for example blows up the REPL since it prints forever
thats the extracted manifest data. you can probably limit it to the stuff you actually need
Hi, is there a easy shadow-cljs project/template to get started with creating addons/extensions for browsers like firefox and chrome?
@neupsh it is still kinda undocumented but it works and is used by people. https://github.com/thheller/shadow-cljs/issues/279
https://github.com/fulcrologic/fulcro-inspect/blob/master/shells/chrome/manifest.edn