This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-18
Channels
- # aws (3)
- # beginners (18)
- # boot (3)
- # cider (47)
- # clara (54)
- # cljs-dev (62)
- # clojure (104)
- # clojure-berlin (1)
- # clojure-denver (1)
- # clojure-italy (1)
- # clojure-nl (22)
- # clojure-russia (30)
- # clojure-spec (28)
- # clojure-uk (95)
- # clojurescript (31)
- # cloverage (1)
- # cursive (1)
- # datomic (17)
- # duct (4)
- # emacs (27)
- # fulcro (36)
- # graphql (1)
- # hoplon (1)
- # jobs-discuss (1)
- # lein-figwheel (1)
- # lumo (2)
- # off-topic (44)
- # om-next (5)
- # onyx (29)
- # precept (1)
- # re-frame (8)
- # reagent (7)
- # ring (1)
- # ring-swagger (2)
- # schema (4)
- # shadow-cljs (185)
- # spacemacs (21)
- # specter (59)
- # tools-deps (7)
- # vim (15)
- # yada (1)
Can I configure shadow-cljs to write .nrepl-port
like figwheel does? That way cider could auto-detect the port
@wilkerlucio had an idea how to resolve pretty much all problem and it seems to work very nicely. nothing released yet but I wrote down some stuff here: https://github.com/thheller/shadow-cljs/issues/279
@thheller interesting, one thing occurred to my mind, if we add new files, that would mean we also have to change the manifest during dev?
new cljs files
you only specify :entry
. if the entry "reaches" the newly added file it will be automatically added
so, the files listed there are the goog bootstrap things, + shadow things, + cljs things + 1 single file for the user things, is that correct?
"background":
{"persistent":false,
"scripts":
["out/background.js", "out/cljs-runtime/goog.debug.error.js",
"out/cljs-runtime/goog.dom.nodetype.js",
"out/cljs-runtime/goog.string.string.js",
"out/cljs-runtime/goog.asserts.asserts.js",
"out/cljs-runtime/goog.reflect.reflect.js",
"out/cljs-runtime/goog.math.long.js",
"out/cljs-runtime/goog.math.integer.js",
"out/cljs-runtime/goog.object.object.js",
"out/cljs-runtime/goog.array.array.js",
"out/cljs-runtime/goog.structs.structs.js",
"out/cljs-runtime/goog.functions.functions.js",
"out/cljs-runtime/goog.math.math.js",
"out/cljs-runtime/goog.iter.iter.js",
"out/cljs-runtime/goog.structs.map.js",
"out/cljs-runtime/goog.uri.utils.js",
"out/cljs-runtime/goog.uri.uri.js",
"out/cljs-runtime/goog.string.stringbuffer.js",
"out/cljs-runtime/cljs.core.js",
"out/cljs-runtime/clojure.string.js",
"out/cljs-runtime/shadow.cljs.devtools.client.console.js",
"out/cljs-runtime/shadow.module.shared.append.js",
"out/cljs-runtime/demo.chrome_bg.js",
"out/cljs-runtime/shadow.module.background.append.js"]},
that stuff is generated. only stuff in manifest.edn
matters. manifest.json
is generated.
yeah, but I'm wondering if when I add a new file, the generated list of scripts will have to change
because I think when you change that, you also have to go into the extensions pages and refresh the extension manually
the manifest is not auto-updated afaik
but that has several other drawbacks so I opted not to do that by default. but it could be configured to work that way
not quite, I just tested on the background page here
the current setup does update
the content-scripts are the exception I think
the old one
:chrome-background {:target :browser
:output-dir "shells/chrome/js/background"
:asset-path "js/background"
:devtools {:devtools-url ""}
:modules {:main {:entries [fulcro.inspect.chrome.background.main]}}}
right now I only refresh the extension when I have to change the content-script, if we go that direction I'm afraid we will have to do more ext refreshes
ok, let me see if I'm also on the same page as you
I'm talking about the new changes you proposed for the compilation
in your example, the background page will change from the current browser :target
and instead will pre-compile and use the files from the manifest directly
is that correct?
browser target I mean, the way we compile the background
the entire chrome extension is compiled in one build yes. :browser
is no longer used.
that I think its a downgrade in the experience for development
because using :browser
, I don't have to refresh the extension when I do updates on the background code
I just checked
about changing code, and refreshing the background page only (open devtools for it from the extensions pane, and use cmd+r in the inspector tool, it refreshes)
I took a tiny screen recording to show it
true, but I think we don't to change that most of the time
check the log
after the refresh, the log comes with the new message
(sorry, I should frozen the last frame more, it transitions back to the gif start quickly)
I update the bg code, shadow reloads it, you see a new message, then I go into the bg and refresh
the same file is loaded, now with the updated message on the log
that is also live-reloading so I'm still confused what you are actually talking about
no, I thin you are missing the refresh on the devtools pane
when the log is cleared and started over
check when the elements pane got reset and re-rendered
that's a refresh
there is no problem here, this is the good version, using browesr
I'm afraid that will be lost with the new proposed changes
and instead of a simple refresh on the devtools panel, I'll have to go in the extensions page and ask a refresh there
cool, that's good, I was afraid that would break
what about new files, had a chance to test that?
I'm not sure about how chrome caches things there, considering the same scenario doesn't work this way with content-scripts (where I have to go into the ext pane and refresh there every time it changes)
the reason it seems to update when using :browser
is that the code is loaded async and from remote
nothing in this is specific to :browser
. all of this could work identically in :chrome-extension
async has other issues in particular with :background
since you can't use OnInstalled
for example
humm, I think I'm getting it now, OnInstalled
can only run in the initial code, so async loading for it on :browser
is broken, correct?
half-correct. the :browser
loader is semi-smart and detects if it can document.write
which means it appears sync
my idea was just trying to reduce the number of times we have to refresh the ext from the extensions page (or dont increase it, hehe)
do not think that you are giving up anything when not using :browser
. that is not the intention here. keeping all the features but with easier configs is the goal. :browser
is too complicated and does too many things we don't need
gotcha, thanks for the clarification 🙂
meaning putting everything into one build driven by the manifest.edn
vs. having multiple separate builds
so the most important question currently would be to decide if there is a reason NOT to combine everything into one build. in which scenario would that NOT work.
I think currently the major pain point you described already, that's how to switch the REPL target
I think :content-scripts
can always load async remotely. they don't have any special lifecycle callbacks anyways right? eg. no OnInstalled
humm, there is a catch there
for example
I might want to inject things on page DOM via content-script before the user code is there, (like settings a flag so the user know an extension is installed)
if the code loads async, that will break I think
so, problem only for document_start
one idea, what you think on using namespaced keywords for shadow things? like :shadow/entry
?
so we can avoid collisions with regular manifest things
yeah, just trying to be future proof
we never know if chrome might decide they want to use entry
key for anything
@wilkerlucio (js/chrome.runtime.reload)
actually does a full reload of the extension. could bind that to a key in cursive.
interesting
excluding the closure compiler from clojurescript & adding in the version you specified fixed it 👍
So is figwheel needed when using the shadow-cljs dev tools? It pretty much live-reloads and exposes the nrepl server, so is figwheel needed for some other cases?
ok cool. Also yesterday you gave me a startup app that instructed to use npx server and watch app seperately, but shadow-cljs watch app
does both in one command. Other than having the ability to stop one or the other, is it advised to use the shadow-cljs command over npx?
npx
is only useful in case you do not have shadow-cljs
installed globally. if you do you can skip npx
.
it becomes more useful when you start using REPLs and multiple builds. just using watch
is fine if you only have one build
great, loving it so far, still have yet to catch your interview on defn podcast
congrats man 🙂
how we can package libraries for things developed with Shadow? had anybody ever done that? how to share the npm dependencies? stil using lein for generating the jar?
yeah I still haven't worked on that. pretty complicated topic. lein
works fine so I recommend that.
npm deps you can put into a deps.cljs
at the root of you lib via {:npm-deps {"react" "some-version"}}
but given the state of :npm-deps
support in CLJS that might not work too well outside shadow-cljs
for my case I'm ok been shadow only
but there is not much now, I think if we want to actually use the npm ecosystem, shadow is the only way until cljs core / closure figures on that side
do you know if there is a tool to read from package.json and spit on deps.edn?
well, so shadow is the way to go 🙂
one thing just occured to me about the manifest.edn
, did you though about how to add extra compilations there? (besides content-script and background)
another common cases are js for popup pages, devtools, apps...
and those don't have a place in the regular manifest, they are loaded via html
you already have an idea of what that will look like?
ok, but that should be under some other key right? to avoid collision with regular manifest keys
namespaces are another option, but I feel like the nesting might be less confusing
ok, I'll stop breaking your focus 🙂 I'll try to think on those too and I'll let you know if get some idea
is that shadow retuning status code 130
on ctrl+c expected?
cli version: 2.3.23 node: v8.11.2
are you using the 10?