This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-28
Channels
- # bangalore-clj (1)
- # beginners (67)
- # braveandtrue (179)
- # cider (28)
- # cljdoc (1)
- # clojure (132)
- # clojure-conj (3)
- # clojure-dev (1)
- # clojure-finland (6)
- # clojure-nl (2)
- # clojure-russia (6)
- # clojure-spec (19)
- # clojure-uk (62)
- # clojurescript (90)
- # clojutre (5)
- # component (2)
- # cursive (30)
- # data-science (1)
- # datomic (42)
- # duct (9)
- # emacs (1)
- # figwheel-main (158)
- # fulcro (57)
- # funcool (3)
- # hoplon (1)
- # jobs (17)
- # mount (38)
- # off-topic (15)
- # re-frame (53)
- # remote-jobs (2)
- # schema (11)
- # shadow-cljs (299)
- # spacemacs (25)
- # specter (2)
- # tools-deps (54)
- # vim (11)
- # yada (6)
Can't get deps.edn and Reagent working together. I end up getting The required namespace "react" is not available, it was required by "reagent/core.cljs".
I have :deps true
in my shadow-cljs.edn
, and :deps {reagent {:mvn/version "0.8.1"}}
in my deps.edn
@grav deps.edn
doesn't cover installing npm
deps at all. npm install react react-dom create-react-class
is required manually since reagent
doesn't declare those :npm-deps
.
https://github.com/thheller/shadow-cljs/issues/382 I'll try to find a way to make this smarter
version ranges as the default, running globally vurnable things on install,postinstall,etc
yes, so just have yarn or npm do all the work of resolveing the dependencies. Just have 1 file to assemble all the deps needed to build a project. :npm/yarn
or :npm/npm
to specify the resolver.
yarn
also uses the same npm registry so it doesn't really make sense to differentiate between yarn
and npm
in the dep location
the only point is simplification. Especially if the package.json is stored in a .jar file. Just manual labour.
and why would it then make a difference if the user makes a package.json or deps.edn stores it, same end result
you pass the entry point to npm install and lib A and lib B to nested dependencies and npm resolves it like it would
yes, my whole point is to leave it to npm, if deps.edn declares a npm dependencies, then npm should treat the npm dependencies like it was a module.
I guess I don't understand what you are saying then. npm
doesn't know about deps.edn
I'm saying CLJ lib A declared :deps {"react" {:npm/version "v16"}}
and lib B declares :deps {"react" {:npm/version "v15"}}
you pass libA and libB to npm. Then you have conflict like you'd always have in this situation.
node_modules/libA/package.json["react" "v16"]
node_modules/libB/package.json["react" "v15"]
entry ./package.json
{"dependencies":{"libA" "...", "libB": ".."}
yes, so it would exist in ~/.m2, tools.deps, could theoretically, read the deps.edn from the maven resources, and spit package.json, or somehow resolve it, and run npm install
from the directory it was called from to generate node_modules
when and only npm modules are a dependency of an application, which are these days, most clojurescript apps.
but yes, if all the maven deps are themselves a module, they may resolve conflicts, but they are themselves a module but not their dependencies. So it doesn't make sense what I said, in the sense that we want the dependencies to be first class, and then it surely can conflict.
but don't take my work for any of this. I'm not qualified to commend on any deps.edn
issues. ask in #tools-deps what their plans are
unrelated, I worry about react17; componentWillReceiveProps
and componentWillUpdate
are going to get deprecated and renamed with UNSAFE_
prefix. React libraries are going to get "doesn't work on my computer" storm soon.
has anyone seen this error with datascript and shadow-cljs before?
seems to have gone after a rebuild
what do “js/my-fn is shadowed by a local” errors point to?
navigate-fn in this case is: js/history.replaceState
or js/history.pushState
interesting
removing:
(and (relative? url)
(exists? navigate-fn))
fixes it
and its down to the (exists? ...)
call
using (some? ...)
works
oh really?
would js/history not be a global though?
i guess it cannot see that at compile time
good to know
When using shadow-cljs with deps.edn say I have one build :app
and I have two aliases :dev
and :production
in my deps.edn
is this not enforced in other compilers?
even if I were to break the build :app
into two (dev and prod) specifying the alias seems to take place outside the :builds
value; on the same level actually.
@urbanslug that is not possible, a build cannot be tied to an alias
{:deps
{reagent {:mvn/version "0.8.0"}
re-frame {:mvn/version "0.10.5"}
day8.re-frame/http-fx {:mvn/version "0.1.6"}
secretary {:mvn/version "1.2.3"}
com.andrewmcveigh/cljs-time {:mvn/version "0.5.2"}
proto-repl {:mvn/version "0.3.1"}
devcards {:mvn/version "0.2.5"}
binaryage/devtools {:mvn/version "0.9.10"}
day8.re-frame/re-frame-10x {:mvn/version "0.3.3-react16"}}
:aliases
{:dev
{:extra-deps
{day8.re-frame/tracing-stubs {:mvn/version "0.5.1"}}}
:prod
{:extra-deps
{day8.re-frame/tracing {:mvn/version "0.5.1"}}}}}
Error building classpath. Could not transfer artifact thheller:shadow-cljs:jar:2.6.3 from/to clojars (
these -stubs
packages are starting to bug me ... I really dislike the entire concept
but it's not on clojars
> just add thheller/shadow-cljs {:mvn/version "2.6.3"}
to your :deps
Exception in thread "main" java.io.FileNotFoundException: Could not locate shadow/cljs/devtools/cli__init.class or shadow/cljs/devtools/cli.clj on classpath.
yup, well shadow-cljs is installed in the node modules via npm not for my user but I did run clj after adding it to deps.edn so it should be
day8.re-frame/re-frame-10x {:mvn/version "0.3.3-react16"}}
thheller/shadow-cljs {:mvn/version "2.6.3"}
should be
day8.re-frame/re-frame-10x {:mvn/version "0.3.3-react16"}
thheller/shadow-cljs {:mvn/version "2.6.3"}}
weird how $ clj
and $ clojure
failed after removing my ~/.m2
I thought they called the clojure bin in my /usr/bin/clojure
I'm waiting for my yarn dev
to finish now. It should work.
What are best practice for :output-dir
, :output-to
, :test-dir
for :target
: :browser
:node-test
browser-test
. I mean i see paths like public/js
, resources/public/js
, resources/public/js/out
and I am trying to solve the puzzle why so many paths. Should best practice be to use path in resources
or not etc. Maybe not super important but I am trying to do some guideline.
its just a directory. the reason is that many people want to package their .js
files into uberjars. that is easier with resources/public
depending on the server you run you can either serve a "resource" which means something that is on the classpath and the resources
directory typically is in lein
I don't do that since it also requires restarting your clojure server to update .js
files
I have an uberjar for my server but that server is configured to serve the public
directory via files
If you serve the frontend via reverse proxy (nginx) you don't have to restart the backend
@urbanslug of course you do. if you only serve resources.
thats cheating and not using the uberjar. in that case it would actually be waste to have the .js
in the uberjar at all
After change to:
:output-dir "public/js"
But it is running. Also I restarted server and watch app
I've noticed that tests (karma) don't work when I'm using deps.edn
such as in https://gitlab.com/urbanslug/sniff
is that expected?
$ CHROME_BIN=/usr/bin/chromium y test
yarn run v1.9.2
$ karma start --single-run
28 08 2018 20:01:16.832:INFO [karma]: Karma v3.0.0 server started at
28 08 2018 20:01:16.834:INFO [launcher]: Launching browser ChromeHeadless with unlimited concurrency
28 08 2018 20:01:16.839:INFO [launcher]: Starting browser ChromeHeadless
28 08 2018 20:01:17.119:INFO [HeadlessChrome 0.0.0 (Linux 0.0.0)]: Connected on socket VQ5gfyizvjWfbb8bAAAA with id 10361789
HeadlessChrome 0.0.0 (Linux 0.0.0): Executed 0 of 0 ERROR (0.003 secs / 0 secs)
error Command failed with exit code 1.
info Visit for documentation about this command.
$ y compile-tests urbanslug@urbanslug
yarn run v1.9.2
$ shadow-cljs compile test
shadow-cljs - config: /home/urbanslug/src/clj/sniff/shadow-cljs.edn cli version: 2.6.4 node: v10.8.0
shadow-cljs - starting via "clojure"
[:test] Compiling ...
[:test] Build completed. (42 files, 0 compiled, 0 warnings, 2.68s)
Done in 18.53s.
when my shadow.cljs file looks like so:
:dependencies [[cljs-ajax "0.7.3"]
[reagent "0.8.0"]
[re-frame "0.10.5"]
[day8.re-frame/http-fx "0.1.6"]
[secretary "1.2.3"]
[com.andrewmcveigh/cljs-time "0.5.2"]
[proto-repl "0.3.1"]
[devcards "0.2.5"]
[binaryage/devtools "0.9.10"]
[day8.re-frame/re-frame-10x "0.3.3-react16"]
[day8.re-frame/tracing "0.5.1"]
;[day8.re-frame/tracing-stubs "0.5.1"]
]
;:deps true
what am I even looking at? what is it supposed to say? I do not know or use karma
. what is the issue here?
you are saying the when :deps true
and running shadow-cljs -A:dev compile test
the tests somehow behave differently?
yes > you are saying the when :deps true and running shadow-cljs -A:dev compile test the tests somehow behave differently?
I didn't have the -A:dev in compile test earlier but it doesn't seem to have made a difference.
A successful test run
CHROME_BIN=/usr/bin/chromium y test urbanslug@urbanslug
yarn run v1.9.2
$ karma start --single-run
28 08 2018 20:07:52.737:INFO [karma]: Karma v3.0.0 server started at
28 08 2018 20:07:52.740:INFO [launcher]: Launching browser ChromeHeadless with unlimited concurrency
28 08 2018 20:07:52.745:INFO [launcher]: Starting browser ChromeHeadless
28 08 2018 20:07:53.041:INFO [HeadlessChrome 0.0.0 (Linux 0.0.0)]: Connected on socket Bw4Yh8tnbBy6CuC7AAAA with id 59771053
LOG: 'Testing sniff.core-test'
HeadlessChrome 0.0.0 (Linux 0.0.0): Executed 1 of 1 SUCCESS (0.008 secs / 0.002 secs)
TOTAL: 1 SUCCESS
Done in 1.17s.
CHROME_BIN=/usr/bin/chromium y test urbanslug@urbanslug
yarn run v1.9.2
$ karma start --single-run
28 08 2018 20:14:29.089:INFO [karma]: Karma v3.0.0 server started at
28 08 2018 20:14:29.091:INFO [launcher]: Launching browser ChromeHeadless with unlimited concurrency
28 08 2018 20:14:29.095:INFO [launcher]: Starting browser ChromeHeadless
28 08 2018 20:14:29.380:INFO [HeadlessChrome 0.0.0 (Linux 0.0.0)]: Connected on socket KQ9yl27ydQsVoQa2AAAA with id 37908417
HeadlessChrome 0.0.0 (Linux 0.0.0): Executed 0 of 0 ERROR (0.003 secs / 0 secs)
error Command failed with exit code 1.
info Visit for documentation about this command.
------------------------------------------------------------
$ y compile-tests urbanslug@urbanslug
yarn run v1.9.2
$ shadow-cljs -A:dev compile test;
shadow-cljs - config: /home/urbanslug/src/clj/sniff/shadow-cljs.edn cli version: 2.6.4 node: v10.8.0
shadow-cljs - starting via "clojure"
[:test] Compiling ...
[:test] Build completed. (42 files, 0 compiled, 0 warnings, 2.17s)
Done in 15.98s.
hmm I guessed that it had to do with the source paths but the dev server was working with the source paths in shadow-cljs.edn
so I couldn't have guessed it
shadow-cljs the npm package is just about starting a JVM with the proper JVM dependencies loaded
unfortunately its pretty tough to check what you actually do in deps.edn
so its rather hard to debug
I see > shadow-cljs the npm package is just about starting a JVM with the proper JVM dependencies loaded
idk what quality of examples you require but I'm offering that one there. If I had it at the start it would've made my life a lot easier.
so basically what you're starting are web sockets to update the UI and listening for file changes
yes I resolve all the files that your build needs and package them together so you can load them in your page
Because it's really easy here. I can have a person work in react and the default export just works
those would be the fancy compiler tricks I guess. I made a few modifications since I wanted to use that myself. other CLJS tools can't do that yet no.
Any chance to lift this restriction? At least outside of project, I'm locally debugging a lib via npm link <libname>
, I could theoretically copy over the files, but perhaps lift it, if the file was seen to be a symlink, otherwise keep the same behaviour.
https://github.com/thheller/shadow-cljs/blob/016c0c87241ba8bb3a5d753774c052c8661ac8ba/src/main/shadow/build/npm.clj#L431-L433
its actually a different issue I think. it just shouldn't use the canonical file at all
> A canonical pathname is both absolute and unique. The precise definition of canonical form is system-dependent. This method first converts this pathname to absolute form if necessary, as if by invoking the getAbsolutePath() method, and then maps it to its unique form in a system-dependent way. This typically involves removing redundant names such as "." and ".." from the pathname, resolving symbolic links (on UNIX platforms), and converting drive letters to a standard case (on Microsoft Windows platforms).
java.nio.file.Path
Path resolve(Path other)
Resolve the given path against this path.
If the other parameter is an absolute path then this method trivially returns other. If other is an empty path then this method trivially returns this path. Otherwise this method considers this path to be a directory and resolves the given path against this path. In the simplest case, the given path does not have a root component, in which case this method joins the given path to this path and returns a resulting path that ends with the given path. Where the given path has a root component then resolution is highly implementation dependent and therefore unspecified.
ah resolve is of course just like in node.fs, watched an example of stackoverflow before reading the docs, I never posted that 🙂
sometimes I wish I was using Path
for everything. File
really isn't all that great anymore.