Clojurians Log v2

feels like there's a new CLJS release looming, is there anything blocking it?

@dnolen I've been getting my head around what you said re: https://clojurians.slack.com/archives/C07UQ678E/p1586970679096300 and Krell etc. Although I think I understand this now, I don't feel like the news announce and the amended webpack guide make the picture as clear as it could be wrt cljs libraries having npm dependencies - how current tools support this, how they might in future etc. If I find time I could try adding PR's for what I think is missing to explain: "You can now publish ClojureScript libraries that depend directly on the JavaScript ecosystem without additional ceremony and be confident that the whole community can benefit regardless of what other JavaScript and ClojureScript build tools they may prefer." FWIW I've made a repo that follows the new webpack guide, but tries to depend on a lib that declares :npm-deps https://github.com/henryw374/cljs-webpack-bundle-using-lib-with-npm-deps . As you say 'cljs is currently either all Closure or :bundle' so this is not expected to work. I guess another angle on this is that afaik cljs libs using foreign code (e.g. the popular cljs react libs) will probably not yet be dropping cljsjs dependencies in favour of :npm-deps. It's actually not clear that a majority of potential users have any npm setup at all (but it'd be good if the Clojure survey asked this explicitly )

@henryw374 you need to run clj -m cljs.main --install-deps to actually get the :npm-deps

getting the deps and the bundle stuff are independent things

@henryw374 reagent already supports using react from :npm-deps instead of CLJSJS

we'll cover the lib publishing part in a separate guide, the webpack guide doesn't cover the install step because in this case it doesn't need to

Hi folks, I'm working on the cljdoc-analyzer project and I got a failure by analyzing specter 1.1.3 package in cljs environment. After some works, I realised that the call of cljs.analyzer.api/analyze-file function on the specter.cljc file produce a crash. I'm definitely not able to figure out what's wrong. So to help the investigation, I create a demo repo of this crash: https://github.com/frozar/cljdoc_specter_support As the specter package can be use in any cljs project, maybe the call to the cljs.analyzer.api/analyze-file function is not good in the repo above. On the other hand, maybe the parse step of cljs.analyzer.api/analyze-file simply failed on this file (for a reason which has to be highlighted). I would like to understand what is wrong here, to be able to fix cljdoc-analyzer. If anyone has a clue, I would appreciate ^^

@fabien.rozar what is the stack trace?

@henryw374 what is the full stack trace?

Attached file. to recreate, clone that repo and run 'clj -m cljs.main -co build.edn -v -c -r'

@henryw374 minor thing but remove :install-deps from your config

If you will, I share the generated file here.

@henryw374 what JDK are you using?

that stacktrace is very strange

but how else to get the :npm-deps picked up, other than including :install-deps compiler opt? I'm on openjdk 11.0.2.

@henryw374 try with JDK 8 please

@henryw374 :install-deps doesn't pick up :npm-deps

it triggers an install on every build

you almost never want it

I'll probably deprecate this option in the future

If you deprecate, what's the api equivalent? A function that takes the config? Asking because I use cljs programmatically.

@dominicm deprecation doesn't really mean removal

just an warning of some of some kind discourage future use

I know. But if I'm not using cljs.main, I don't know how to install deps otherwise.

I try to keep up with changes to apis.

the warning won't be at the level of the API - probably only cljs.main

so you'll be fine

I also add the stack trace to the repo, just in case.

Ah, so cljs main will deprecate it, not the api. Cool.

fwiw we fully embrace the Rich Hickey stance on API changes - i.e. NO

@henryw374 all of this needs a lot of documentation - i understand why you might be confused

great. I think I did know about this a few years ago 😉

well probably the only thing that might ever cause an API change is project sustainability

like dropping all the less used REPLs in the next release - but that's really a special case

@dnolen here’s a link to view this outside slack, I’ve looked at this before and couldn’t make much sense of it so we’d very much appreciate your eyes on this 🙂 😄 https://github.com/frozar/cljdoc_specter_support/blob/master/resources/clojure-7761295136030698780.edn

@fabien.rozar @martinklepsch let not use threads in this channel

@fabien.rozar the stack trace says the failure is in Clojure

not the analyzer

and it gives a precise location, please drop a link to that failing line in the original source

https://github.com/redplanetlabs/specter/blob/40add561b6298743a0d61def212b1b6b3f3a376b/src/clj/com/rpl/specter.cljc#L1452

are you sure the version of Clojure you're running has coll?

the likelihood that the exception is wrong is small

In the project.cljs of this minimal repo, I specified [org.clojure/clojure "1.10.1"] I can use the coll? function from a clojure REPL in this minimal repository... For me, I think I have the coll? function and this exception doesn't make sense. @dnolen can you reproduce the bug locally? You just need to clone the repo and make lein run to get it (normally...).

sorry I don't have time to look at that

an exception like that is almost never wrong

the failure is in Clojure

You right, is a kind of Clojure question, but this exception appear by using a function from [cljs.analyzer.api :as ana], that's why it seems to be related to ClojureScript... Maybe I should post it in the #clojure channel.

@fabien.rozar actually it might not be I'm not really what's going on in that trace

it looks like it's wrapped in something, sorry

@fabien.rozar let’s get together and try to further reduce the repro

@fabien.rozar what version of ClojureScript is this?

the other possibilty is that your ClojureScript version is wrong

hrm yeah no way coll? has existed since 2011

@fabien.rozar that namespace ... is complicated

I suspect there's a macro bug here - if so there's nothing you can do about it

@martinklepsch ^

I use [org.clojure/clojurescript "1.10.597"] just in case

@martinklepsch yes, I think the best would be to get a more synthetic example...

I looked a bit more closely at the source and trace - I really don't know - seems weird - agree that making a more minimal example would be useful