https://gist.github.com/coetry/c664947e3500ca1b7dbe4c842d91a625

I can’t seem to get garden in my repl although I have it in my build.boot

#object[TypeError TypeError: goog.net.jsloader.load is not a function]
TypeError: goog.net.jsloader.load is not a function
    at adzerk.boot_reload.client.patch_goog_base_BANG_.goog.global.CLOSURE_IMPORT_SCRIPT ()
    at Object.goog.importScript_ ()
    at Object.goog.writeScripts_ ()
    at Object.goog.require [as require__] ()
    at Object.clojure.browser.repl.bootstrap.goog.require ()
    at eval (eval at <anonymous> (), <anonymous>:1:6)
    at 
    at 
    at cljs.core.MultiFn.G__12138__2 ()
    at cljs.core.MultiFn.G__12138 [as call] ()

I get that when I enter (require '[garden.core :refer [css]])

Caveat: I don't do any cljs work but that sounds to me like something might be pulling in an incompatible version of the Google JS library?

Hmm, I have the latest cljs version in there, so I would hope it would load the correct one

but that’s possible

How do you start your repl? (I just created a test project with that build.boot file and ran boot dev and that started the watcher...)

I connect to the nrepl

through cider

and then run (start repl)

(start-repl)

Hmm, I get this error when I try that:

boot.user=> (start-repl)

java.lang.IllegalStateException: Can't change/establish root binding of: *cljs-repl-env* with set

you have to visit localhost:3000

to establish a websocket connection

hold on, let me post the whole project to github with the source fiels

Cool. Learning how the whole cljs thing works is something I should do so this will help 🙂

https://github.com/coetry/coetry-cljs

🙂 I’m itching to do some serious web dev with full-stack Clojure, currently trying to do static react sites. Having the components and css all represented in native Clojure data structures is amazingly simple and powerful

I haven’t even start playing with Macros yet! I’m kinda new to the Lisp world, but am so ready to dive in! I just gotta get past some battles with the tooling lol

OK, all caught up... the WS stuff doesn't seem to work in Microsoft Edge so I had to switch browsers...

(probably because I'm working across VMs)

And I can repro... that's a good first step...

Ugh I wish there was an easy way to handle version conflicts 😔

Bing turns up a commit on the Google closure library that "deletes deprecated goog.net.jsloader.load" https://github.com/google/closure-library/commit/988ff900886e959a888485ee56d1540d1bf2f29d so the problem seems to be picking up a more recent version of the Google closure library (from the latest ClojureScript) and Adzerk boot-reload doesn't work with it.

@coetry Looks like you need this in build.boot:

:dependencies '[[org.clojure/clojurescript "1.9.908"
                  :exclusions [org.clojure/google-closure-library]]
                 [org.clojure/google-closure-library "0.0-20170519-fa0499ef"]

That at least lets the require of Garden complete without an error...

hmmm interesting, maybe that’s a bug experienced when developing in the repl, because i know you for sure want google closure in production

that’s where all the js optimizations happen

but you don’t need that in dev

let me try that out

So I guess the Adzerk guys need to update boot-reload to work with the latest Google closure version.

Note that I excluded it from clojurescript and added a specific dependency on an older version

Ahhhhh, gotcha. I’m gonna try that right now. Thank you so much for your help Sean!

Hmm, that doesn't get you much further it seems

cljs.user=> (require '[garden.core :refer [css]])

cljs.user=> (css [:body {:font-size "32px"}])

#object[ReferenceError ReferenceError: Can't find variable: garden]


eval code
eval@[native code]

ahh, that was the second error i was getting

So I'm not sure what to suggest at that point.

I’ll continue tinkering with it and see what I can do

This is why we gave up trying to use cljs about two years ago and figured we'd revisit it some day once tooling has become less fragile...

Sorry I can't help more. Dinner time here...

No worries at all, I appreciate the time! I’ll ask the #clojurescript guys

@coetry BTW, I looked a bit more deeply at boot-reload and it has almost no dependencies and nothing to do with cljs so it's not at fault. Apologies to the Adzerk guys for jumping to that conclusion.

Hopefully someone in #clojurescript -- or someone here with more knowledge of the cljs ecosystem -- can help you. I'll be interested to know what the solution is either way (I'm not in #clojurescript tho').

@coetry There are parts of garden that does not work entirely in cljs

you could just fire-up a clj-repl

Anyone an idea why some lein plugins that are not listed in a jar’s pom.xml would still leak into boot? Example boot -d morse show -d

how does boot do the voice notifications? like when it says “2 Warnings” and stuff like that?

@seancorfield: It works perfectly fine from a standard clj repel as @hkjels mentioned

I see the strings generated by the (css) function

Is it possible to control the ordering of the resulting classpath inside a :dependencies vector? I had assumed they'd be ordered by appearance, but they seem to shift if things depend on them.

before I file a bug report, has anyone else noticed that in boot 2.7.2, exceptions raised gy boot print a "line: ..." number but do not print a "file: "some/file.clj"" where the exception was thrown? Changing my boot.properties version to 2.7.1 or 2.7.0 print like I'd expect, but it breaks in 2.7.2

https://discuss.gradle.org/t/how-do-i-control-the-order-of-compile-classpaths/5329/4 seems this might not be possible

@dominicm what's your use case for reordering dependencies?

currentoor on macs there's a 'say' command on macs that it shells out, iirc it uses espeak on linux (if available)

Bad jar not vendoring it's dependencies @micha

drewverlee re: cljs it's not clear that boot pods are fundamentally possible in node, since node doesn't have classloaders, which are the underlying tech on the jvm

Duplicates on the classpath

@dominicm that's a problem that is outside of the dependency resolution scope i think

drewverlee the fileset and command line parsing stuff is probably ripe for node. another node build tool, broccoli, on which embercli is based, has a fileset-like thing in it

one thing you can do is maybe fix the bad jar's pom

or something like that

@dominicm maybe a good solution is to vendor that jar yourself and add exclusions

and finally you could use a pod maybe to segregate it

I think they want it like this. But it also means I have to figure out maven. I probably will do that :)

@alandipert oh i see, thanks

i'm relatively ignorant of maven eccentricities, but to me it seems not good for lein to add plugins as deps

It is probably not lein, but the plugin

Looking in more depth, it's only one of the three :dev :plugins so it makes me wonder whether the author has ultra as a non-dev dependency, maybe in their ~/.lein/profiles.clj?

Ultra attaches itself to lein using middleware hook: https://github.com/venantius/ultra/blob/0.4.1/src/ultra/plugin.clj#L94 https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md#project-middleware

pom.xml is what you have in your project and maven renames it to *.pom as part of deploy, yes?

And in this case, ultra modifies the projects :dependencies and adds dependency there

So that all the other lein tasks see the ultra also

I think I've dealt with this problem somewhere, but can't remember where

Huh, ultra seems to work differently if it is defined on project dev profile, vs. ~/.lein/profiles.clj

If it is in ~/.lein, it is not added to pom.xml

Based on comparing pom.xml and morse-0.2.4.pom, it isn't added to the pom.xml if it's in :dev as one of the :plugins either, but it is added to morse-0.2.4.pom... So I guess we just chalk this up to ultra being "badly behaved" and leaking into the artifact's .pom file (but not pom.xml -- so why are those different?)

cc @venantius hey! maybe you can shed some light on the above issue and/or have heard of it before 🙂

@venantius to sum the issue up: it seems that the :dev dependency on ultra somehow leaks into the .pom file of the deployed library [morse “0.2.4”]

I don’t think ultra should be set as a dev dependency

The Ultra README recommends using it in your local ~/.lein/profiles.clj

I would absolutely believe that Ultra is responsible for the issue here as it does modify both :dependencies and :plugins

@venantius did you consider using :scope "test" when adding it to :dependencies? — I guess many people will just not read the note in the README

@venantius morse doesn't have ultra as :dev dependency, but as dev plugin

I was not aware of `:scope “test”

@juhoteperi that is to be expected - ultra is a plugin

Probably something strange going on with lein profiles also, as there was some dfiference between having ultra on ~/.lein and project.clj

though it does inject itself as a dependency

Does the :dev profile leak? Leiningen claims that the :dev profile has ^{:pom-scope :test} set already

If I understand ultra code correctly, the dpendenciy in injected directly to the project, not to project's dev profile?

well at the point at which lein middleware runs I believe the profile has already been resolved

so you can’t modify other profiles

It doesn’t look like plugins in the dev profile get the pom-scope limitation attached. Does that propagate the plugin via the pom? That would seem potentially undesirable.

One test case would be to create project with lein new, add ultra to dev plugins on project.clj and run lein pom, ultra will be included in deps

Not sure if pom task works the same as packaging the lib

when running lein jar, the pom.xml doesn't have ultra dep

To be honest, I’m inclined to push this back to Boot. It doesn’t sound like Ultra leaks to pom.xml, just to pom, which includes a specific note that it’s Leiningen-internal

*Or, this is a Leiningen issue and shouldn’t be leaked to pom

The pom file contains an explicit warning that its data should be considered non-canonical

hmm, now I'm unsure what the original problem even was

the .pom file is the one in the maven repo, right?

because looking at the morse jar, it looks fine

The problem is that somehow ultra ends up in pom but not in pom.xml and that Boot seems to rely on pom

Oh now I see it

when you say "ends up in pom" do you mean the .pom file in the maven repo?

~/.m2/repository/morse/morse/0.2.4 master*
❯ cat morse-0.2.4.pom | grep ultra
      <artifactId>ultra</artifactId>

because that file is the pom.xml file the user uploaded to clojars or maven central when they pushed the jar

when you push to a maven repo you upload a jar and the associated pom.xml

as two separate artifacts

This is a problem with Leiningen also, which can be checked by adding [morse "0.2.4"] dep to a Lein project and checking lein deps :tree (ultra will be transitive dep of morse)

the pom.xml file you upload when you push becomes the morse-0.2.4.pom file we see when we download it from clojars

so something added ultra to the pom.xml that was uploaded via the push task in leiningen

also the part about "It should not be considered canonical data." is misleading

since the pom you share in the maven repo is by definition canonical

that's the whole point of it

Yeah, that file is used by Maven/Lein/Boot always

by apache aether really

boot delegates all of that

maven-resolver nowadays 🙂

oh sweet!

or well, I guess we haven't updated yet

point being that boot isn't involved with dependency resolution directly

deps are resolved by the standard maven tooling

so what i think is happening there is this

when you do the leiningen equivalent of boot push it generates a pom.xml to upload to the repo with the jar

ultra has done some things internally in leiningen that cause it to think that ultra is a dependency without test scope

so when leiningen generates that pom.xml it has ultra as a normal dependency

and that gets uploaded to clojars

the pom.xml file in the jar is generated by a different code path in leiningen probably

one that does not see changes made by ultra's injection process or whatever

I'll open Leiningen issue about this, seems quite strange

can we not just do like [morse "0.2.4" :exclusions [ultra]] or something similar?

Yes, that should work as a workaround

ah ok sorry

I think I found the reason, both Lein and Ultra work correctly 🙂

Morse adds Ultra to :dev profile instead of :user profile

... no this doesn't make any sense, as :user shouldn't be used on project.clj

but :repl profile works

has anyone else tried boot uberjar with CLJS 1.9.908?

failing catastrophically for me

and by that i mean boot-cljs 2.1.2 with advanced optimization

log: https://gist.github.com/kanwei/b94e07c49930c1b05dbb08666f7f4792

@kanwei Doesn't look like that would be caused by Boot-cljs. It would be best to try to reproduce this with cljs.jar (https://clojurescript.org/guides/quick-start) and if this happens with that also, open issue on Cljs

is it possible to list dependencies in separate files? e.g. separated by scope?

test-dependencies.edn dev-dependencies.edn prod-dependencies.edn.

I think this is stupidest idea. But maybe it's worth blurting it out

😄

direct dependencies is straightforward

but if you want to include transitive dependencies it's more complex