This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-04
Channels
- # announcements (7)
- # aws (5)
- # babashka (72)
- # beginners (43)
- # calva (12)
- # cider (9)
- # clara (3)
- # clj-kondo (12)
- # cljdoc (32)
- # cljs-dev (10)
- # cljsrn (1)
- # clojure (78)
- # clojure-dev (50)
- # clojure-europe (17)
- # clojure-gamedev (8)
- # clojure-nl (1)
- # clojure-spec (30)
- # clojure-uk (3)
- # clojurescript (52)
- # core-async (1)
- # cursive (5)
- # datomic (8)
- # emacs (58)
- # events (2)
- # fulcro (5)
- # graalvm (7)
- # holy-lambda (37)
- # honeysql (9)
- # jobs (5)
- # leiningen (3)
- # lsp (7)
- # lumo (2)
- # malli (3)
- # meander (13)
- # membrane-term (64)
- # missionary (19)
- # music (3)
- # nextjournal (8)
- # off-topic (29)
- # pathom (16)
- # polylith (14)
- # portal (16)
- # re-frame (2)
- # reagent (5)
- # sci (14)
- # shadow-cljs (20)
- # spacemacs (6)
- # sql (1)
- # tools-deps (58)
- # vim (14)
Not sure if this is the right place to post this, but I am running into an issue running codox
over a .cljc
file with reader conditionals:
Could not generate clojure documentation for sitefox.deps - root cause: clojure.lang.Compiler$CompilerException Syntax error macroexpanding clojure.core/ns at (sitefox/deps.cljc:1:1).
Syntax error macroexpanding clojure.core/ns at (sitefox/deps.cljc:1:1).
Call to clojure.core/ns did not conform to spec.
...
Execution error (IllegalArgumentException) at codox.main/ns-matches? (main.clj:73).
no conversion to symbol
Any tips on how I can diagnose/fix this? The file is here for your reference: https://github.com/chr15m/sitefox/blob/main/src/sitefox/deps.cljcnote this isn't necessary in ClojureScript since all those characters are valid in symbols
however note that shadow-cljs has non-standard semantics here which probably creates a lot of confusion - I'm not sure if nbb
follows the standard behavior
to clarify here: the only non-standard thing shadow-cljs is providing here is outputting ESM code. besides that it just provides "express"
or whatever to import
rather than require
. The default mess is because of difference of the host runtime not because of anything shadow-cljs or nbb are doing.
whether its "express$default"
or express$default
makes no semantic difference to shadow-cljs either
so you can require node modules now w/o strings? sorry I missed if that changed (or just misunderstood) - I thought it had to be a string to call it out
you always could. I never diverged from the "standard" in that regard. I just personally recommend using strings to distinguish pure npm/JS requires from CLJS requires. personal subjective preference since strings need to exist anyways.
I still absolutely do not like that the presence of a folder in node_modules
decides whether a require is valid or not
I have changed the requires to use the symbol style instead of strings but I am seeing the same error from codox. I've attached the traceback in case somebody has time to help me diagnose.
Whoops, sorry.
@chris358 codox just needs to understand that you can use string namespaces in other CLJS dialects, or it should allow a set of cljc features to just skip those branches
Do you think I should I take this to the codox issue tracker or is it something I can solve? Sorry I'm a bit out of my depth here. 😅
I have removed the string namespaces and the error is still occurring.
It probably treats the :org.babashka/nbb
as Clojure as opposed to CLJS. Or does it also complain if you get rid of the :org.babashka/nbb
branches?
Testing now.
custom reader conditionals - this cannot work if you're going to use this you should expect most tools to fail
the fact that shadow does is not a good thing for a incredibly long list of reasons including the above
@U050B88UR That's actually not true. Clojure does support this. It's a property of clojure.tools.reader and also the Clojure reader that it just picks what it's interested in.
@U04V15CAJ it does not
unless something changed - you are only allowed to use :clj
:cljs
or :cljr
nothing else will work
So CLJS barfs when you use a :random/dude
reader conditional? Why the closed world assumption? Clojure itself supports it.
Also see this README:
https://clojure.org/reference/reader#_reader_conditionals
> Implementors of non-official Clojure platforms should use a qualified keyword for their platform feature to avoid name collisions. Unqualified platform features are reserved for official platforms.
that's been changed since I last looked at it - been years - so the rules have been softened a bit
originally only the three above were allowed - I was actually there (at Cognitect) when it was decided upon because ClojureScript really needed it
@chris358 you need to alter the reader somehow to codox to handle this stuff, not sure how that is done
Ok thanks @U050B88UR I will file an issue on the codox repo and see if weavejester has time to look.
shadow doesn't take a name at all. the user is free to specify whatever but it is up to the user. I just added it to solve a problem actual projects had
all I did was make :reader-features configurable. there is nothing set or used by default that isn't already standard
Maybe should update the docs to avoid having users use non-namespaced names to specify platforms - other thing I wonder if we should suggest shared naming conventions i.e. :cljs/browser
:cljs/node
:cljs/react-native
etc.
perhaps it worth updating the docs to recommend the using namespaced keyword for custom usage - on a bigger note I wonder if we should recommend "standard" names, i.e.
@U050B88UR why does CLJS expect a fixed set of reader features in .cljc files rather than an open set? I'm not sure if I get the issue. The namespaced ones are only for "non-official" (non-Cognitect?) Clojure implementations like :org.babashka/nbb
- I'm actually the first one who conforms to this rule afaik. CLJS could of course add more :cljs/*
ones for specific use cases.
I wasn't entirely joking about :cljs/es6
, I've discussed this idea with Thomas once. This could be used to account for both CJS and ES6 targets in one file, since the surfacing libspec forms tends to be different in ES6 due to different export structure (the thing with default, etc).
Ah ok thank you.
@suskeyhose re: bound-fn
many years ago some options were considered but they were all quite complex w/ a lot of tradeoffs - in Clojure of course you have real vars and threads, so bound-fn
is quite natural to express
That's fair. In my particular usecase for clojurescript it'd really only be helping out with laziness. It's not a huge deal to not have it, just a bit unfortunate it's missing.