This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # babashka (137)
- # beginners (96)
- # calva (3)
- # cider (11)
- # clj-kondo (8)
- # cljs-dev (161)
- # cljsrn (21)
- # clojure (78)
- # clojure-europe (47)
- # clojure-france (1)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-spec (24)
- # clojure-uk (9)
- # clojuredesign-podcast (4)
- # clojurescript (39)
- # conjure (2)
- # core-async (27)
- # cursive (36)
- # datomic (54)
- # emacs (6)
- # figwheel (9)
- # figwheel-main (46)
- # fulcro (25)
- # graalvm (8)
- # helix (30)
- # hoplon (6)
- # hugsql (3)
- # jobs (5)
- # leiningen (7)
- # luminus (12)
- # nrepl (20)
- # off-topic (20)
- # pedestal (16)
- # re-frame (14)
- # reagent (3)
- # reitit (3)
- # remote-jobs (5)
- # rum (25)
- # shadow-cljs (60)
- # spacemacs (10)
- # vim (2)
- # xtdb (36)
Hello. I noticed a problem with the REPL resolving aliases in certain situations. Here are my repro notes, tell me if I should raise a JIRA ticket. https://gist.github.com/olivergeorge/37f420d369e3a4d60c5bf5ff2c171664
give master a try - if it turns out to be problematic might revert - but it seems like it could work
@dnolen It was to gain more parallelism, IIRC. You can analyze in one thread effectively, while emit in the other.
Oh, sorry, I read that but I read it as "analyze". Hrm. I don't recall anything around
analyze-path off the main thread.
Ahh, so you are wondering if it is safe to put it off to the side and re-join with its results after the REPL is live. That sounds like a good tactic to reduce latency-to-first prompt, yes.
(I'm often afraid of the unpredictable effects of these concurrent threads, but immutability saves the day.)
pretty minor thing: the webpack config doesn't really need to exist. It can be replaced by the cli entirely, meaning no need for a (complex looking) file.
would be nice for both to be listed in the PR rather than just the smaller cli version
@bhauman I added reconnect to browser REPL, that said I could't get the browser REPL to disconnect spuriously - probably because we had some nice fixes a while ago that made things more stable.
right. its nice to have the quick version when just getting a hello world version. and then when you need to expand that for a real world app nice to have the full config that's equivalent in case it needs to be a bit more complex
What sort of "real world" things need to go in there. I've always just left it alone after creating it (with the old version of the guide).
@bhauman not seeing the rationale bit - elaborate? just to avoid logic, you can just eval it?
one problem you'll have is if you want to use the modules from CLJS and they're not in
@bhauman I'm not following how is this related to hot loading? oh you mean like multiple compiles triggered by N expressions?
I was being specific to a REPL that operates over client polling, hot reloading via a changes file is less critical
@dominicm the easiest way right would be to get that into your
node_modules first - i.e. make it package
@dnolen and then it has a build step in making it a package which turns it into cjs or something?
Then cljs will generate a
require() for it, and then webpack will be in charge of that?
@bhauman I'm not following anymore - sorry more focused now. I don't really see a need to change the REPL more generally?
and I like polling for that a lot because - file watching involve a bunch of stuff I don't want to do
thats just a detail but its nice to know which files the user actually changed versus which are dependently compiled
;; needed for advanced but also fine in dev I assume? (from https://clojurescript.org/guides/webpack)
Just to double check, I know there's the $ stuff in the works (which would be PERFECT!), but for the meantime is this considered valid?
(require '[front-end :as front-end]) (front-end/utils.Auth.get "/some-url") Where utils is a folder, Auth is the default export of
Auth.js (an instantiated class) and
.get is a method on that class?
I'm guessing I might need a
.default in there.
It always take the "newest" version of the thing and in JS community, break things is almost a "good pratice"
["npx" "[email protected]" ...] should avoid problems in the future (but it still can be problematic, once it pins only
webpack, any subpackage required by range can break in the future
what? that is absolutely not valid?`
utils.Auth.get only does property access, it will not look for files, folders or anything of that sort? it is valid if
front-end exports the object structure like that but not otherwise
I guess in this case maybe something like
"front-end/utils/Auth" I'm not that familiar with conventions around exporting a Node module name
@dnolen yeah, you're right. Just figured that out. Then it's Auth/default.get I guess. I feel the need for $ more now. I think the generic solution is the right one.
the tsickle stuff is actually pretty interesting - https://medium.com/appmonet/using-closure-compilers-advanced-optimizations-with-webpack-816214b2fd5c
there’s sometimes where I really want to drop down into JS and write some super performant/mutable stuff. TS makes it way easier to write JS. having it hook into closure would be 🚀
@lilactown I’m sure you are aware of this already, but you can do that now, by writing a goog module compatible file, on the correct classpath?
heh I'm less interested in the JS writing part - which yes we need to improve, and more into the there's all this TS we can we use
I'm trying to find the xkcd about how humans can find anything interesting, if they're locked away in a box for an extended period for example. But <insert that>
and because it's Java/C# like it mean libs are less likely to do things that are overly dynamic
I think someone in a JIRA ticket pointed out https://github.com/google/incremental-dom
huh webpack does tree shaking of ES2015 import now https://web.dev/commonjs-larger-bundles/
Is this an obvious "oh, you've done X" mistake?
Looks like find-sources is returning an empty list, which add-preloads does a
(first post) on and gets
nil. I'm not sure if
-find-sources should be returning an empty list or not? I have no :modules in my opts (from a
prn), and that seems to populate something of importance to cljs?
blugh. I'm definitely in confused territory. That error doesn't happen with figwheel - but now I'm not getting an npm_deps.js produced, even though it's required by the main .js file...
@dnolen RE my first error, I can reproduce in mies by: bumping cljs & removing the
"src" from build.clj
Fixing that in my build.clj (by providing "src") gets me to the same place as figwheel, but now I can inject printlns :)
@dnolen RE my second error, npm_deps.js is written, but was not a sibling of my output-dir. I was using:
:output-to "target/dev/public/frontend-output.js" :output-dir "target/dev/public/frontend.out"
Parcel.js is an order of magnitude (4s vs 300ms) faster than webpack, and seems to produce js which is half the size in dev.