This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-10
Channels
- # announcements (15)
- # bangalore-clj (1)
- # beginners (207)
- # calva (22)
- # cider (4)
- # clara (73)
- # cljs-dev (7)
- # cljsrn (4)
- # clojure (125)
- # clojure-dev (38)
- # clojure-europe (2)
- # clojure-india (11)
- # clojure-italy (11)
- # clojure-nl (14)
- # clojure-russia (22)
- # clojure-uk (32)
- # clojurescript (30)
- # cursive (11)
- # datavis (2)
- # datomic (14)
- # editors (3)
- # emacs (3)
- # hyperfiddle (4)
- # juxt (13)
- # klipse (1)
- # luminus (5)
- # nrepl (7)
- # off-topic (9)
- # overtone (13)
- # portkey (1)
- # re-frame (15)
- # reagent (13)
- # ring (30)
- # schema (4)
- # shadow-cljs (108)
- # spacemacs (8)
- # specter (3)
- # sql (2)
- # testing (11)
- # tools-deps (21)
- # unrepl (4)
I’m observing something weird when using specs to validate a reagent atom — should I be careful when importing namespaces only for side effects (that is, to register specs etc)?
My app.main
(entry point) requires my app.state
(and uses a bunch of functions) which in turn requires my app.spec
— and uses nothing from there. However I get an error like so
main.js:3045 failed to load app.state.js Error: Unable to resolve spec: :base/count
at Object.cljs$spec$alpha$the_spec [as the_spec] (alpha.cljs:121)
at Function.eval [as cljs$core$IFn$_invoke$arity$5] (alpha.cljs:518)
at Function.eval [as cljs$core$IFn$_invoke$arity$4] (alpha.cljs:513)
at Object.cljs$spec$alpha$def_impl [as def_impl] (alpha.cljs:314)
at eval (state.cljs:120)
at eval (<anonymous>)
at Object.goog.globalEval (main.js:2188)
at Object.env.evalLoad (main.js:3043)
at main.js:3261
Where :base/count
is defined in app.spec
like so (s/def :base/count (complement neg-int?))
— and if I put that declaration in my app.state
ns, the problem goes away.
It’s my first time using spec from CLJS, so perhaps shadow CLJS might not be the culprit. I’m using :loader-mode :eval
if it makes any difference.
OK, got it — I had two shadow-cljs builds running — one for running the tests in node, one for the browser. Stopping them both and running only the browser one seems to fix things, :loader-mode :eval
still works.
Ouch, adding cljs.spec to the project hits me with a 60kb of optimized javascript. I guess DCE isn’t working in this case?
I opened https://dev.clojure.org/jira/browse/CLJS-1701 a while ago but nobody seems to care 😛
Yeah, but still, 20kb of gzip was like a 15% increase of my build. I’m not dying, but would be good to fix.
Yeah, I guess I can do that — but eventually I’d like to actually validate some things at runtime.
Could be that the reason it’s not fixed yet is that people actually use it at runtime and gladly pay the price. I was a little bit surprised to see the gen.test stuff in there.
it really cannot be fixed in the way it is written right now. so you basically need to rewrite the entire thing
@thheller I have to thank you (again) for coming up (and maintaining) shadow-cljs. It’s a fantastic tool. Please apply for Clojurists Together again.
@thheller looking into now builders, wondering if shadow-cljs supports all requirements to make one? https://zeit.co/docs/v2/deployments/builders/developer-guide/
here are builders for other langs: https://github.com/zeit/now-builders
not sure if Java is available to builders? need the JVM to compile. besides that is should be easy to create a builder
same here, I’m puzzled. zeit now just has such an amazing dev experience, I’d love to use it with CLJS!
not sure. they pride themselves with extremely fast builds / deploys https://twitter.com/rauchg/status/1060587045515493376
already hate that everything is expressed by filenames. gotta hate languages without proper namespacing
can’t have everything. the motive seems to be to cover as many langs as possible. the lowest common denominator of any popular lang is the file, so it makes sense. imho, it’s quite impressive, this is powered by 4 langs https://monorepo-v2.now.sh/
here’s the next builder taking a seq of files: https://github.com/zeit/now-builders/blob/master/packages/now-next/index.js#L79
and the config determining how many builds a project has: https://github.com/zeit/now-examples/blob/master/nextjs-news/now.json#L6
equally clueless here. however, I think getting clojurescript into now would be great. it’s similar to the deployment part of datomic cloud, just for cljs and other langs. Since now is very popular among hobbyists the exposure of cljs in their builders could also attract / lower the bar for beginners
not sure what exactly it is building in the first place with just plan .js
files for example
there might be a way to hack by compiling first and then building with the node and/or static builder
I guess it just needs one file to trigger everything but that file can be shadow-cljs.edn
same as
{
"version": 2,
"builds": [
{ "src": "docs/package.json", "use": "@now/static-build" },
{ "src": "blog/package.json", "use": "@now/static-build" }
]
}
does the npm package handle installing the java, clojure if it’s not there or does it expect it on the classpath
@U050CJFRU I just did my first test now deployment. As expected it is trivial if you compile the code locally and just deploy the generated .js
creating a custom builder would then just involve something that downloads the JVM and stuff. not sure thats worth the effort since debugging stuff is pretty annoying
:now-lambda
{:target :node-library
:exports-var demo.now/handler
:output-to "out/demo-now/index.js"}
https://github.com/thheller/shadow-cljs/commit/0b7b22855be0f2272e3b8e90fdf4e2f4e2a637f7
should probably extract that into a proper example. just wanted to get something running quickly and this does the trick
to be honest the now builders currently just look like a super terrible CI implementation
thanks @thheller. Yes builders do look messy. Still when they work they work! Just want to write and deploy cljs quickly (and cheaply which lamdas are)
right now "quickly" probably means compiling locally and deploying the compiled .js files directly. downloading java, maven deps, npm install on each build is probably way too slow when using a custom builder
and are you loading any other bundles on the webpage you’re running your CLJS code?
Has anyone used shadow-cljs with single-spa?
@mateus.pimentel.w shadow-cljs ensures that cljsjs is not used. so no need to worry about including it.
@leocardosoti many people do yes
I'm coding two very different but related builds with different package.json files: one a :node-library
running Google Cloud Functions, and one a browser app that communicates with those functions via Firebase. I'd also like to share some common code between them. Is there a way to specify different package.json files per build in one shadow-cljs and build these both from one shadow-cljs server
run, or is it best to run two separate shadow-cljs instances?
Also, is there a way to run a watch on a node-library and prevent the repl and websockets stuff loading? It's causing errors in the local firebase cloud functions emulator. I'm only able to get release builds to work with it, and it'd be nice to just have the release build get triggered when the code changes, but otherwise have it be exactly the same code as a release build.
@thosmos what I recommend doing is keeping a dedicated directory for your node builds/packages
and the CLJS isn't kept in that directory at all. the compiler output just goes there
@leocardosoti oh. didn't realise that is a framework. no not aware of anyone using that
i mean the single spa framework
@thosmos what kind of issue do you get with the functions emulator? you can just disable the websockets stuff with :devtools {:enabled false}
(like in the above config)
The emulator error is
error: SHADOW import error /Users/thomas/Develop/take2/experiments/threshold-functions/functions/.shadow-cljs/builds/gcf/dev/out/cljs-runtime/shadow.js.shim.module$ws.js
...
Error: Cannot find module 'ws'
I'm still getting an error firebase > error: no "source-map-support" (run "npm install source-map-support --save-dev" to get it)
but I think I remember a shadow config to disable source-maps