Fork me on GitHub
#cljs-dev
<
2020-04-25
>
john00:04:17

So, are you saying that one would use :require instead of :import for the goog libs? Isn't it the case that you'd usually only ever see an inner class $ situation in CLJ when using the :import context? If we want to ride on existing idioms, would it make sense to keep this behavior to the :import context? I love the $ idea!

john00:04:59

plus, :import is for external stuff anyway

john00:04:30

As an OG Clojurist, I vote for the $ syntax. Strongly dislike adding : within symbols, since some things like to store keywords concatenated as a string (without a space).

didibus00:04:49

Two things to consider: 1. Would there ever be ambiguity with choosing $? Could JS start using this for other thing? What about Clojure? 2. Is it easy to auto-complete? For example, $ can act as a marker, saying, ok now auto-complete given what's before what can come after

john00:04:24

Also, how does :refer work, if the referred thing is a data property rather than a fn? Does it just become the value of the property?

john00:04:39

And my last question would be: What are the possible ways in which a Clojure user's expectations of the $ symbol for inner classes be violated when trying to use this feature in CLJS land? Any?

didibus00:04:54

Man, JS modules are a mess 😛 I don't think I even really understand how things are imported in JS, so I can't contribute too much. But I always thought it was really confusing that I can't just :require x.y.x :as foo for everything. So if this gives me that, I'd say +1. And the whole thing with import I still don't really understand what needs imported and why.

didibus00:04:02

Also, I would find it weird that I need to use ns for requiring/importing. I would always expect that I can choose to use require and import on their own, outside of ns as well.

john00:04:34

congruence of semantics between clj and cljs for import and require would be sweet

didibus00:04:55

So I think whatever CLJS does with ns, it should be compatible with require and import, or it needs to add new functions, if there was a :default now you need a matching default function, etc.

john00:04:08

@didibus I think the default would go as a tag in the require or import vector, not as a top level command like require or import, so wouldn't have an associated fn. But yeah, the default stuff is all another language to me too.

didibus00:04:50

I personally like to try and be as consistent with Clojure. But I also think there shouldn't be anything that is not possible to import due to this constraint. And maybe for me, the latter is more important. Like there's nothing more frustrating but to hit a wall and realize there's just no way to require what you need. Which I'm concerned a little bit in case $ can clash. Would there be a way to say escape the one that is for require vs the one that is in the name?

lilactown00:04:04

dynamic require is just not something that’s easily supported and my guess is probably won’t be in the near future

john00:04:59

I guess the string version could allow you to escape the $ that happened to be in js name? I never liked the string syntax though.

didibus00:04:21

I hate the string syntax (as a mainly Clojure dev)

lilactown00:04:31

my understanding is that :import would still be there for some google closure interop.

lilactown00:04:17

the proposal is: :require would be used to access CLJS namespaces, external JS packages, and globals importing a JS property as a namespace would be supported using the new feature, at this time the $ in the middle would delimit the package/global and the property

lilactown00:04:09

I think it would be better to use :import to add some new semantic, since it’s used so infrequently, but the semantics we’re talking about (using an object property as a namespace) doesn’t match the semantics of Clojure’s :import at all

john00:04:08

Does the inner class thing and the nested object thing really differ so much? And how so?

lilactown00:04:14

import in Clojure brings in a Java class as a value the nested object require we’re talking about brings in a JS object as a namespace

john00:04:15

In code, rather than in namespace declarations, right?

lilactown00:04:47

example:

(ns 
  (:require
   [window$console :as console]))

(console/log "hi")

john00:04:13

Right, but (.-log console) wouldn't work, right?

didibus00:04:25

Hum, Clojure's import is a bit crappy though, it doesn't follow require syntax, so everyone get it mixed up all the time. And it has no features, can't alias, refer is implicit, etc. But hey, I guess in Clojure the ship as sailed. That said, the syntax is the same as for namespaces outside of it. If you imported a.b Foo you can do Foo/ for everything else. And I think one thing confusing in CLJS, is that there's no logic. In Clojure you can say.. require for Clojure stuff, import for java stuff. It be nice if that was true in cljs as well

john00:04:35

Well, then it's seems like a value

lilactown00:04:53

I don’t know that it would disallow, but it does allow (console/log ,,,) which is typically reserved for namespaces

lilactown00:04:19

CLJS doesn’t actually have namespaces as values, so

lilactown00:04:36

and a lot of objects masquerade as namespaces already

john00:04:33

Yeah, I guess there's an argument for not inheriting CLJ's namespace ugly-parts

lilactown00:04:42

:import alone also doesn’t really solve the problem we started with:

(ns 
  (:import
   ["react" default]
   ["@corp/my-lib" default]))
you get two default bindings, need to introduce some way to alias them, you might even want to add :refer….

didibus00:04:50

Can someone explain to me what we mean here between namespace thing and object thing? Like what's wrong with: (import [window console]) and then I can do console/log ?

john00:04:13

To be honest... If I go back to the first time I saw the $, I think I wished that it could have been a ., just to minimize the noise. But if there's any utility keep it, and it's not an artifact of java-isms, then I'd love to see $ smooth out the interop between CLJS and JS.

didibus00:04:41

In Java you don't actually use $ for inner class, that's only used in ASM, which Clojure compiler uses. So you can say it is more of a Clojure thing then a Java thing in my opinion

john00:04:30

ah, right... a java-interop-ism, under the covers

lilactown00:04:36

it's a JVM thing? 🙂

didibus01:04:14

I guess a JVM thing, but Clojure could have chosen whatever symbol it wants, Java for example uses .: outer.inner.

john01:04:06

Well, there might have been a decision at the time, where maybe using . caused some ambiguity

didibus01:04:13

So in fact, lots of Java folks get tripped up in Clojure, and ask how to access an inner class, because they try . and it doesn't work 😛

didibus01:04:12

Ya, I think making it $ is equivalent to Clojure's /. So now given any prefix a.b.c$d you know to look up a.b.c for d. Otherwise you'd need some more elaborate logic I think. Like can you find a.b.c.d in the map? No, ok try a.b.c ? No, ok try a.b, ok found it, ok now from it look for c.d, etc.

didibus01:04:12

Anyways, so if I understand the issue, this is about how do you alias and refer JS dependencies? Cause without those features, seems import could work for everything no?

john01:04:08

Well, after thinking about it some more, the :import syntax is generally disliked, by everybody, in it not having the :as and :refer and friends. And if we're putting this stuff there just to be like CLJ, then would you also disallow :refer? Seems draconian...

didibus01:04:01

I guess I'm just trying to unravel the "issue". In Clojure, you want to use a function from Java, you always need to prefix the classname or even fully qualify it. Like I said before, this seems a bit underwhelming in features, but it also motivates people to wrap Java stuff in Clojure.

john01:04:12

There's a bunch of weird import/export scenarios in JS that this feature would nicely address - one of which was the default issue

lilactown01:04:03

I think there are two things to consider for the proposal of using :import for JS libs: • import in Clojure land typically imports a class that's used as a value, not a namespace, so it would be a slight semantic diff • you would want things like :as , :refer , :rename , etc. to avoid collisions which would be additional syntax inside the :import section dnolen has been pretty explicit that he isn't interested in extending the ns form and adding more differences between Clojure and CLJS, but maybe these differences are more palatable seeing as import has very little direct relation between the two platforms

john01:04:03

I also personally like how it addresses "the differences between clojure and clojurescript" issue... if only a little

didibus01:04:28

Right, but all of these "weird import/export" seems out of place for Clojure. It seems JS is trying to bring so much "user convenience". Like I'm so lazy, I don't even want to choose what to import, I want the export to define defaults that magically appear in my import and might change at any upgrade because the export controls it

john01:04:25

@didibus but we need some way to map the lib in... and js/ or "[email protected]" is a wild west

john01:04:32

@lilactown what do you mean by "`import` in Clojure land typically imports a class that's used as a value, not a namespace, so it would be a slight semantic diff"

didibus01:04:48

So maybe this is where I'm not familiar with the complexities. But why can't you just: (import whatever) and then do (whatever/some-fn) and (.- some-field whatever) ?

john01:04:13

When used in an ns declaration, isn't it [Some$Foo bar]? Where that's more-so an ns than a value. Or are you talking about using Some$Foo/bar in code?

didibus01:04:47

You asking me? In Clojure it would be (import some.package OuterClass$InnerClass] and then in code you do: (OuterClass$InnerClass/some-fn)

john01:04:09

@didibus because if the lib exported as, for instance, default, then neither of those existing ways get at the export correctly. I can't remember the details, but I've been bit by the complexity of it.

john01:04:32

ah, right

lilactown01:04:53

I thought that foo/bar was reserved for namespaces. clearly I'm mistaken

john01:04:41

well, you can access a static method off the class using foo/bar as well, right?

john01:04:27

Well, more like Foo/bar

didibus01:04:35

Same access syntax for both

didibus01:04:26

The only difference is you would never do: (.-field some-ns) but you might do: (.-field SomeClass)

didibus01:04:10

Well... hum, actually I'm a bit fuzzy here, might still be (SomeClass/field) actually.

didibus01:04:43

But that field access is syntax sugar for the . special form, which would be: (. SomeClass -someField)

didibus01:04:34

It be nice if someone could describe such an edge case that makes it you can't do things exactly how they are in Clojure to me 😄

john01:04:20

Another question: what would this whole solution look like if . was used instead of $? Would that introduce any ambiguity?

john01:04:57

If not, is there any point in adding $ at all?

didibus01:04:23

It still all seems to me like all the challenge here are due to having used require for JS stuff as well, and not just cljs stuff.

john01:04:32

Wasn't it mentioned somewhere above that . was also a possibility?

lilactown01:04:31

. is used in JS package names so can be ambiguous

didibus01:04:34

I think I understand the intent at first, like, hey JS modules are closer to Clojure ones, so why not pretend like they are Cljs libs, but clearly, they were different enough that now we have a weird state of affair

john01:04:45

So that's out

john01:04:29

Well, that wouldn't work for us anyway? :thinking_face:

john01:04:37

I don't think cljs's require has gotten weird yet. Except for the string requires

didibus01:04:52

Which I think is where dnolen is coming from. Like saying, ok we don't want a js-require. So either we want to use import, but that's not convenient because people seem to really want to be able to alias, or refer things from JS lib as well. If so, then we must find a way to make them work as if they are ClojureScript lib with standard require. And now the question is.. can we?

john01:04:03

I guess that's a necessary escape hatch though

john01:04:33

@didibus Yeah, sounds like david and team got most of the way there over the last few years and a kind of solution is finally coming together.

john01:04:34

Might not solve all edge cases, but it doesn't sound like the string require escape hatch is going away.

didibus03:04:54

I think the string require is a good reason for needing some form of aliasing

didibus03:04:15

Since you wouldn't even be able to type the fully qualified version in code

didibus03:04:38

unless you allowed "lib"/some-fn

didibus03:04:47

which seems a worse compromise

didibus02:04:32

Speaking of which, it is also inconssitent with Clojure for enums to be EventType.value and not EventType/value. Don't know what the rational was for that

didibus03:04:33

Also, would ClojureScript be able to handle dynamic imports?

potetm03:04:40

@didibus There’s no such thing as a class in JS. It’s all objects. You always access objects with ..

didibus04:04:52

I'm not sure what you mean by always access objects with . ?

potetm12:04:52

. is the interop special form.

potetm03:04:07

/ is used exclusively for namespaces in cljs

didibus03:04:25

But that's a decision made within the ClojureScript project

didibus04:04:42

And it appears to me here we are suggesting that we want to lift Objects in JS which act as namespaces as if they were namespaces and treat them so.

frozar04:04:04

What an animated (and overwhelming) debate, I wish a good rest to the CLJS team during this week-end. Event if I arrived after the battle, I thought maybe I can add something. I was wondering if is was possible to get the name of all npm package. The answer is "yes", and guess what: there's a npm package for it "all-the-package-names". It just output every package on stdout.

npx all-the-package-names | grep "coffee.*maker" | wc -l
4

npx all-the-package-names | grep get-or-set | wc -l
1
You can find anything there. Yeah, coffee maker packages exist (you can check it yourself). These JS funny guys have a package for everything! I you do get how huge is this ecosystem, I highly recommend you to take a look at the generated galaxy regarding npm: https://anvaka.github.io/pm/#/galaxy/npm (you should take a seat before using this link). So from there, I check if there's any package with the $ character: no package involved the character, good news! But:
npx all-the-package-names | grep "dollar" | wc -l
123
We're just one step away from it. One day, a JS dev will find to long to use dollar in a package name and will prefer $ instead: concise, explicit, straightforward, only benefits => profits! And who knows, if emoji are allow, why not use them in package name? More seriously, I wonder if they were forbidden characters in package name. I found a npm package which answer this question, "validate-npm-package-name" (https://github.com/npm/validate-npm-package-name): package every where. In its README, you can find the Naming Rules (https://github.com/npm/validate-npm-package-name#naming-rules) of package name. It says explicitly that package name cannot contain these characters: ~)('!* Any character for this list can be used as a delimiter IMHO, and my favorite one is !.

didibus04:04:09

To me, a prototype acts as both a Class and its instance, so I would have found it natural to treat them as a Class as well

didibus04:04:08

@fabien.rozar Good investigation! The other issue is you need it to also not clash with possible ClojureScript namespace names. And the rules for that is it may include: . * + ! - _ ? $ % & = < > : #. Though I guess it already allows $ so if something were to happen, we'd be breaking compatibility if there are any existing namespace with a $ in it

alekszelark11:04:03

Hi guys. I ran into some problems with the latest version of CLJS. I reported about it here https://ask.clojure.org/index.php/9260/some-problems-with-latest-cljs-1-10-741

alekszelark12:04:33

@dnolen any thoughts on it?

dnolen12:04:49

no will have to look at that later

👌 4
alekszelark14:04:42

just added one more issue related to node target

dnolen15:04:11

reproduced and fixed, cutting a release just for the Quick Start - it seems like a pretty old bug

🎉 4
dnolen11:04:22

@fabien.rozar that's useful info thanks, it's been 10+ years of Node and you haven't seen $ in package name, I'm not too concerned at this point, again it aligns with some Clojure-isms so that's a plus

dnolen11:04:32

@didibus no dynamic imports, we're never going to work on that outside of what's needed for REPLs and all the various restrictions that apply for even that case

dnolen11:04:38

@john . just not under consideration - Foo/bar thing from Clojure can't work because Clojure knows that Foo is a class and not a namespace, we don't have this information in ClojureScript generally, including foreign libraries coming from node_modules - there's no type information to figure this out

dnolen11:04:18

@didibus Not really interested in :import it really only serves one purpose - a way to get a certains kind of GCL libraries, it's not relevant outside that use case. The other problem is that :import has a very restrictive syntax, again not interested in any changes - so not useful in this context.

dnolen11:04:05

all the feedback is appreciated. Just want to reiterate not interested in any change to the ns form wrt syntax, if your idea is based on that let it rest 🙂

dnolen11:04:02

$ is still a primary contender given it exists in Clojure in a similar context, it's been used before in CLJS bootstrap, and it's unlikely to clash for cases that matter to most ClojureScript users

dnolen11:04:09

what we're proposing now is about reconciling 2 different but related problems: A) global stuff that's loaded outside of ClojureScript B) being able to treat some property, not nested, of a JS value as a namespace

didibus17:04:16

My confusion here from a mostly Clojure dev is what you mean by "as a namespace"? As opposed to what? You referring to the use of js/ instead?

dnolen11:04:53

(:require [goog.global.Math :as math]) (:require [goog.global$Math :as math])

dnolen11:04:09

is the essence of this proposal, very little else

dnolen11:04:03

it's utility for ES6 default just falls out, not an essential thing

dnolen11:04:39

secondary benefits, for goog.global.Math where GCL has externs we can do the same arity, existence, validation as is done for GCL namespaces

dnolen11:04:48

(doc string too)

dnolen11:04:55

anything that's in the extern

frozar12:04:33

Ok, just to say, concerning cljdoc, its trajectory is clear thanks to the above discussion, thank you 😸 (I just follow the discuss for other issue you're talking, that's it)

roman01la12:04:19

@dnolen after looking more into https://clojure.atlassian.net/browse/CLJS-3159 I now think that perhaps we could have reify* special instead of fiddling with anonymous deftype, this would also align with Clojure, wdyt?

dnolen12:04:36

@roman01la for that why can't you just mark the var as private?

dnolen12:04:04

I don't know why deftype needs to do anything here except preserver the private var meta if it doesn't

roman01la12:04:31

hmm, good point. Would that solve https://clojure.atlassian.net/browse/CLJS-3160 though?

dnolen12:04:40

I left that comment on that one

roman01la12:04:40

I guess it should, will give it a try, thanks

dnolen12:04:43

3160 seems a bit contrived to me - I don't know how these vars would every appear in numeric forms

roman01la12:04:49

> The ns-publics issue is related to the use of reify inside cljs.core/nil-iter's definition and incorrect type information being established: A Var is created, which is tagged as being of function type, when in fact the Var's value is nil. Then when the var special is applied to the Var's symbol, there is a bit of code that would normally conditionally include test meta in the generated Var:

dnolen12:04:47

yeah going to have to look all that later - that's a bit too much for me to load - the public problem is easy and obviously should be fixed

roman01la12:04:27

I can work on that, just need more input

dnolen12:04:06

in the symbol passed to deftype just (vary-meta x assoc :private true)

👍 4
john12:04:04

@dnolen okay, understood. Is it true that $ would only be used in ns declarations? Or could I go (ns (:require [X.Y])) (Y$someFn))?

dnolen12:04:54

I tried to be pretty clear about what I proposed

dnolen12:04:08

if I haven't mentioned then it's not something under consideration

john13:04:33

Didn't you say the main impl would be in the resolve machinery? That sounds like it's usable in code, so I was wondering where you were going with the idea. And you can do (Y$someFn) in Clojure, so I was wondering if the general behavior of $ applied here.

dnolen12:04:31

so just rule out anything not in mentioned in the two forms above

thheller12:04:35

using this example (:require [goog.global$Math :as math]). How do you know at compile time what can be used before $? I mean even goog.global does not exist as a namespace and is itself a property of the goog "global"?

dnolen12:04:25

I said there are two parts

dnolen12:04:41

A) global stuff B) one level $ property access

dnolen12:04:52

both need implementation support

dnolen12:04:10

but how it's going to work isn't really important

thheller12:04:41

so I guess its too early to ask about implementation details? I'll come back in a couple days then.

dnolen13:04:13

implementation details are not a discussion point, and not going to be looking for feedback about that

thheller13:04:14

my concern is about figuring out what can be valid as a "prefix" (ie. prefix$Thing)?

dnolen13:04:29

semantics sure

john13:04:33

Didn't you say the main impl would be in the resolve machinery? That sounds like it's usable in code, so I was wondering where you were going with the idea. And you can do (Y$someFn) in Clojure, so I was wondering if the general behavior of $ applied here.

dnolen13:04:58

@john I would drop this line of thinking 🙂 don't worry about how it's going to work, we're past that part now

john13:04:32

I'm not advocating one way or another. Just trying to better understand what's under consideration

dnolen13:04:59

sure, but the answer is if I didn't mention it above, not under consideration - what's above is it

dnolen13:04:40

goog.global - you can't know what's there anyway, that's the whole point

thheller13:04:05

you used (:require [goog.global$Math :as math]) as an example. I'm trying to figure out how you get to the point of knowing that goog.global is valid and correct? is it just a hardcoded default?

dnolen13:04:08

what we can do is validate against known globals via externs, and warn if foreign entry w/o file isn't provided

dnolen13:04:41

does that answer your question?

thheller13:04:17

sort of don't like the ambiguities that creates though. goog.string.format would also be valid as goog.string$format by that logic. given that it exists as a goog.provide and a runtime "var"

dnolen13:04:25

the ambiguity doesn't seem meaningful though, I don't see how this could lead to any real correctness issues

dnolen13:04:57

the whole point of this idea is that it perfectly aligns w/ object as namespace convention

dominicm13:04:35

Would it be usable for things that are renamed? Eg in the case of goog string? I think I've not well followed what the impact of externs is

dnolen13:04:57

the proposal doesn't change anything about the ns form - all features work

dnolen13:04:17

no limitations

dnolen13:04:50

if you think about the proposal is really just allowing something which already true right now

dnolen13:04:19

in regular JS libraries - objects are used to represent nested namespaces

dnolen13:04:35

in global objects loaded by something else - objects are used to represent nested namespaces

dnolen13:04:01

the proposal just lets you get them even if there is no goog.provide

dnolen13:04:23

which there never will be for global things nor node_modules

dnolen13:04:33

if you squint - this is an incredible minimal change, with significant repercussions that allow to cover all use cases of external JS

dnolen13:04:42

everything can be required normally

roman01la13:04:28

Feedback on :bundle target - Setting :output-to to a different dir than :output-dir breaks import {npmDeps} from "./npm_deps.js";, since the path should be different - :bundle-cmd doesn't output stdout/err of whatever command it executes, which makes it less obvious to find out if something is broken or not

dnolen13:04:54

@roman01la minor ticket + patch welcome for more flexible path, and another one for printing out stderr on failure

👍 4
roman01la14:04:40

I guess there already was a discussion regarding generating JS exports for ^:export vars with :bundle target?

dnolen14:04:47

@roman01la what do you mean?

roman01la14:04:15

To turn (def ^:export x 1) into module.exports.x = cljs.user.x when :bundle target is set

dnolen14:04:39

this seems a bit esoteric for most users

dnolen14:04:21

it's also trivial to do this downstream

roman01la14:04:38

sure, btw who are those most users in your opinion?

dnolen14:04:51

what I mean is I don't really care if you need it

dnolen14:04:57

if it can be solved downstream

dnolen14:04:11

if there's some use case you believe everyone is going to hit then something to talk about

dnolen14:04:13

which is what?

dnolen14:04:07

I also want to point out something which I haven't had time to elaborate is there's a ton of change to make downstream tooling trivial

dnolen14:04:13

w/o a ton of ceremony

dnolen14:04:46

what I'm really tired of is tools that do everything

roman01la14:04:57

yes, I agree

dnolen14:04:25

this is literally what krell does

dnolen14:04:34

just call cljs.main

dnolen14:04:40

to rewrite requires for assets

dnolen14:04:34

instead a morass of plugins and plugin architectures or giant balls of mud

👍 8
dnolen14:04:51

write some functions, make a deps.edn alias

dnolen14:04:53

sleep soundly

dnolen14:04:39

i think the only way to avoid the cluster that is JS is to not publish this stuff

roman01la14:04:42

ho, that's a nice example of using compiler passes

dnolen14:04:53

not try to compose this transformation stuff, if you need it just write 20-30 lines of code

dnolen14:04:50

@roman01la yes so again I haven't had a ton of time to document this

dnolen14:04:06

but I made a lot of things public in the api nses

dnolen14:04:19

there's more work to do here, but I would I like to see people hit that stuff hard

dnolen14:04:24

to do typical custom stuff

dnolen14:04:38

some namespaces like cljs.build.api is krufty

dnolen14:04:54

so it maybe that we need cljs.build.api2

dnolen14:04:24

also later not now I would like to do some of the things that shadow-cljs wrt to the pipeline

dnolen14:04:03

shadow-cljs IMO does too much, has too many options, but the general idea of keeping everything in data and only a final flush to disk is sound and easier to reason about

dnolen14:04:05

and I would like see to public apis for that when we get there

roman01la14:04:44

sounds good, I could help with code or docs/guides, but that would still require some of your time, to put thoughts on paper

dnolen14:04:04

@roman01la I believe you have enough right now to handle the export stuff, just binding a pass around build that collects ^:export vars and then generate the :target-fn

dnolen14:04:23

doing that will probably help us see what's missing to make this cleaner easier

dnolen14:04:59

so the next person can go solve their own problems and not bother me 😉

roman01la15:04:15

sounds like a plan 🙂

dominicm15:04:33

cljs-3233: what does "disciplined" mean here?

dnolen16:04:17

a proper require vs. interacting with global libraries will-nilly

dazld18:04:11

thumbs up! tried out the git url and no more warnings!

dazld18:04:43

updated my original repo with a link to that commit

dazld18:04:53

think it’ll get into the next release?

dnolen19:04:39

there'll probably be one later in the week to address straggling issues

roman01la19:04:06

This one is interesting. Depending on ClojureScript code from JS with optimizations set to :none doesn't work, because ClojureScript output is loaded asynchronously. First browser loads Webpack output, which includes deps loader which only then loads ClojureScript output.

roman01la19:04:03

Also running Webpack in watch mode from :bundle-cmd blocks REPL, which means Webpack process should start in background and then it's a bit more tricky to manage this

dnolen19:04:34

I don't know what you mean at all about the first thing

dnolen20:04:08

running watch form :bundle-cmd is gratuitous

dnolen20:04:42

in the case of Metro the expectation si something else is going to run the bundler

dnolen20:04:02

I don't see why it should be different for any other watching scenario

dnolen20:04:06

there will be zero changes to :bundle-cmd

dnolen20:04:11

except for more error reporting

roman01la20:04:34

yeah I'm just providing feedback from my observations

dnolen20:04:01

yes that's useful - what needed here is just docs about the limitations

dnolen20:04:19

modifying the :bundle-cmd docs now

dnolen20:04:14

Updated. I still don't understand your first comment about :none

roman01la20:04:02

> running watch form :bundle-cmd is gratuitous I have JS module that consumes ClojureScript and renders Reagent component in existing JS code. Here it makes sense to run Webpack in watch mode because JS code is being changed. But maybe that's not where target :bundle should be used.

dnolen20:04:08

sure but you don't need :bundle-cmd

dnolen20:04:15

just run the watcher separately - it's not a big deal

dnolen20:04:31

there's just too many cases where :bundle-cmd isn't going to be sufficient - which is fine

roman01la20:04:10

good point, a not on that in the docstring could be useful

dnolen20:04:26

yes will be there when the site updates

dnolen20:04:35

it explicitly states now you should run commands that exit

roman01la20:04:18

I still don't understand your first comment about :noneHere's network trace. bundle.js is produced by Webpack, the code in this file depends on ClojureScript code which is loaded later.

dnolen20:04:49

oh you have circular deps

dnolen20:04:58

not going to fix that for you

roman01la20:04:35

circular deps? the only thing that I have here is that both cljs and js sources depend on React from node_modules

dnolen20:04:37

or do you just have bidirectional stuff?

dnolen20:04:02

yeah mutual requires

dnolen20:04:16

yeah no good answer here, and probably not going to spend any time on that one

dnolen20:04:44

actually ... maybe

dnolen20:04:04

ClosureBundler is a thing - like prep work to get rid of the debug loader

dnolen20:04:20

not sure when/if they're going to kill it

dnolen20:04:08

@roman01la you could try :whitespace which is REPL compatible

dnolen20:04:53

@roman01la the other option is to have your JS sources go through Closure instead of Webpack

dnolen20:04:29

but I guess you probably want JSX

dnolen20:04:43

then :whitespace is probably best

roman01la20:04:22

not sure about mutual deps, it's just JS code that depends on cljs, but yes, bundling all cljs output into a single file will solve this

roman01la20:04:44

but again, can probably write a custom target-fn to handle this somehow

dnolen20:04:52

You have two different build outputs that depend on each other

roman01la20:04:38

mm, no, just this

import "./out/index.js"
console.log(window.hello_bundler.core);

dnolen20:04:20

Right can’t work

dnolen20:04:26

You can wait for that stuff though

dnolen20:04:31

That’s what Krell does

dnolen20:04:50

in dev Krell waits for the entry point, in prod it just invokes the entrypoint

roman01la20:04:39

Looks like it hooks into closure's debug loader?

dnolen20:04:41

ha not even

dnolen20:04:46

though that would be better

dnolen20:04:54

it just waits for cljs.core to appear then starts

dnolen20:04:38

in dev it's easy, it either exists or it doesn't

dnolen20:04:01

once it exists then you know that goog and all the other stuff is available

dnolen20:04:03

@roman01la the problem with waiting for anything is that goog.base has to be there, but even goog.base is written as a script tag

souenzzo21:04:24

Should I expect some kind of requiring-resolve *function* in cljs in the future? Something using JS import function and GCC code splinting? PS. I know that right now I can use code splitting and dynamic load "directly" from GCC, asking about requiring-resolve in particular

dnolen22:04:56

@souenzzo unlikely to ever have a requiring-resolve