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

@olivergeorge I would say none of these cases are a problem

you have to set :analyze-path

also doing anything here by default may effect existing tooling or expectations

would need to collect some information

a safer way would be something new like :analyze-main and only do it for cljs.main

@olivergeorge hrm I think restricting this to behavior cljs.main could work

give master a try - if it turns out to be problematic might revert - but it seems like it could work

if REPL gets :main then we analyze it in a separate thread

@mfikes related, I can't remember why we didn't analyze-path off the main thread

@dnolen It was to gain more parallelism, IIRC. You can analyze in one thread effectively, while emit in the other.

@dnolen Here is what I'm referring to https://clojure.atlassian.net/browse/CLJS-2896

@mfikes sorry you're probably missing the context

REPL has :analyze-path feature so that you can resolve stuff you know you compiled

but this happens on the REPL main thread while starting

so it slows down startup

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.

https://github.com/clojure/clojurescript/blob/00079768f9104b17f4130cd710a2f636e046cb07/src/main/clojure/cljs/repl.cljc#L1172-L1176

@mfikes there's actually no need to rejoin 🙂

because it runs via bound-fn

Ahh, I forgot we are working in a sane language.

(I'm often afraid of the unpredictable effects of these concurrent threads, but immutability saves the day.)

let's see how this change for :main fares

if it seems ok then we could do it for :analyze-path

Looks like that's done the trick. Thanks.

Specifically, my repro now works as expected against 00079768f9

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.

yeah ["npx" "webpack" "infile.js" "-o" "outfile.js" "--mode=development"]

@dominicm ^

it might be better for templates and tutorials to have that

@bhauman yeah, I was just digging that out :)

@dominicm PR to the guide would be great!

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.

@dpsutton like documenting both ways?

in case you need to expand the config easily?

@dnolen added to my todo list

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

agreed, @dominicm ^

agreed as well

@dnolen I thought more about the polling repl idea

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 all ears

the file should be a truncated log

of evals

@dominicm just that if you have a project and you need to add plugins etc.

it took me a surprisingly long time to figure out that "simple" config

reading webpack docs is a nightmare

or was then I put that together

Still is 😂

@bhauman not seeing the rationale bit - elaborate? just to avoid logic, you can just eval it?

Okay, actually. These 2 things might be related to what I'm currently doing actually. I've got some legacy ESM that I'm integrating into my project. Should I be running that through webpack somehow? Or through the alpha JavaScript modules w/ babel.

@dominicm I would avoid the alpha modules feature for now

one problem you'll have is if you want to use the modules from CLJS and they're not in node_modules

@dnolen just to prevent double evals, missed evals

this could allow multiple evals

if needed

=> 1 2 3 4

I have ESM with jsx in, how should I include that in my project?

1 2 3 4

its just more robust

for little cost

@bhauman I'm not following how is this related to hot loading? oh you mean like multiple compiles triggered by N expressions?

@dominicm so you need what I said, to require your module into CLJS

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?

@dominicm no you don't need to change anything about your code

but it needs to be in node_modules we don't support relative paths

Then cljs will generate a require() for it, and then webpack will be in charge of that?

yep

@bhauman I'm not following anymore - sorry more focused now. I don't really see a need to change the REPL more generally?

there's nothing about the existing browser REPL strategy that poses problems

ok maybe I missunderstood you yesterday

cool then I rescind the proposal 🙂

browser REPL works fine - automatic reconnect addresses reliability

yesterday I was talking about hot-reloading

that the changes file is an easy thing to do for anyone

gotcha

browser REPL can just use it

and I like polling for that a lot because - file watching involve a bunch of stuff I don't want to do

how specifically are you envisioning it using it ?

but once you find the file?

cljs.hot-reloader

just fetches a file, we know goog.basePath so we know where it is

when it gets a new file it calls goog.require that's it

oh but you can poll from the client right?

yes no server stuff here

why form the repl

why poll from the REPL?

that's what I thought you were taking about 🙂

not from REPL, from client

Oh ok

{:preloads [cljs.hot-reloader]}

when you say browser repl

I missunderstood

got it

forget about REPL 🙂

just a hot reloader

understood

browser REPL would just add that preload

absolutely we are on the same page for sure

OK so another suggestion, include compile excpetions, and warnings in the file

[{ns-sym desc-map ...}]

well timestamp somewhere

yep and one more thing

would be super nice mark which files were actually changed versus dependents

thats just a detail but its nice to know which files the user actually changed versus which are dependently compiled

but this is a nice to have and can be a future improvement

@bhauman https://clojure.atlassian.net/browse/CLJS-3254

feedback appreciated

;; 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.

about npx docs 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

@dominicm fine for dev too, yes that require should work

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

oh sorry I missed the end of that sentence

yeah that won't work

@dominicm you really need to :require the same thing you would in Node.js

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

but I'm assuming that relatively easy to sort out

@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.

Where we're not using default it's quite beautiful though :)

@dominicm sweet!

that feature will definitely appear in the next release

the tsickle stuff is actually pretty interesting - https://medium.com/appmonet/using-closure-compilers-advanced-optimizations-with-webpack-816214b2fd5c

There's a lot of TS code out there and probably a lot more DCE friendly

yeah I got super excited about it

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?

I think the key part was that TS makes it easier to write :)

yes, closure JS is very tedious 😛

hmmm interesting

goog.provide("my.ns"); my.ns = function() {}

thats tedious 😉

Oh man, that syntax is so 10 minutes ago. Now we just write $12##$!

it’s mainly the typing

i get ya

I actually enjoy TS’s interfaces type language

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

yeah for sure

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>

I only expect TS to get more and more popular

and because it's Java/C# like it mean libs are less likely to do things that are overly dynamic

plus Google is almost certainly going to go there anyway

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/

Makes sense, that was one of the goals of esm.

Is this an obvious "oh, you've done X" mistake? Caused by: java.lang.Exception: Could not write JavaScript nil

Coming from write-js?

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?

not obvious - might need something minimal here

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...

Something has gone very wrong :)

@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.

@dominicm I'm not completely following but if you believe there's a bug - it should be repro'd w/ just ClojureScript