This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-14
Channels
- # beginners (19)
- # boot (11)
- # cider (59)
- # cljs-dev (292)
- # cljsrn (2)
- # clojure (121)
- # clojure-brasil (19)
- # clojure-canada (2)
- # clojure-france (2)
- # clojure-italy (57)
- # clojure-spec (54)
- # clojure-uk (20)
- # clojurescript (83)
- # core-async (20)
- # cursive (5)
- # datascript (2)
- # datomic (10)
- # duct (25)
- # editors (4)
- # emacs (2)
- # fulcro (5)
- # funcool (1)
- # graphql (2)
- # immutant (8)
- # java (1)
- # jobs (4)
- # jvm (1)
- # keechma (5)
- # luminus (10)
- # off-topic (113)
- # om (36)
- # onyx (11)
- # parinfer (55)
- # pedestal (7)
- # protorepl (28)
- # re-frame (25)
- # reagent (6)
- # ring-swagger (1)
- # shadow-cljs (113)
- # spacemacs (1)
- # specter (23)
- # unrepl (8)
- # yada (8)
hello, i’m noticing some weird behavior with cider. everything (eval, jump-to, docstring lookup) seems to be working except for symbols that get :refer
d in
anyone familiar with that?
@thheller Thanks, just thought I'd mention that the release snapshot analyzer displaying the size usage per dependency is really useful.
the problem is that the closure compiler folks decided to change how the interop between commonjs and es6 works
That's a pity. Nothing critical for me thou. I wish you best luck in solving it 👍:skin-tone-4:
shadow-cljs - updating dependencies
shadow-cljs - dependency update failed - Could not find artifact thheller:shadow-cljs:jar:2.1.10 in central ( )
error Command failed with exit code 1.
I pushed not working state to https://github.com/pepe/two-in-shadows
it works indeed, I defined ripple as js/module$node_modules$$material$ripple$index as workaround and forget to fix it. Thank you very much!
If I’ve got a resources/public/js/test/index.html
and I want it to be visible for the :browser-test
target, is there a way I can tell it to look for index.html
in another :resource-paths
? Right now it only looks at :http-root
. If not, is there a way I can move files, like sift
in boot?
The main idea being I’ve got a shadow-target/
output dir, but I’d prefer not to keep any of those file in the git repo, just have it as a temporary target that can be wiped. Is that possible?
@thheller trying to use vega-lite
:
(:require ["vega-lite" :refer (compile)])
compile
is undefined even though this is synonymous to https://github.com/nesterone/vue-vega/blob/9d7f1b3341471e33b402dc1383266d8570f16cfd/test/unit/specs/components/delegate/vegaLiteDelegate.spec.js
when I type veg
into the browser console, this variable autocompletes module$node_modules$vega_lite$build$src$index and module$node_modules$vega_lite$build$src$index.compile exists. Any ideas what might be going on here?@pithyless do you want to replace the default generated index.html
or do you want to access that file independently?
I was trying to replicate my boot
setup where resources/*
where in git and all the compiled output stuff was in shadow-target/*
as it stands, :test-dir
will be a combination of stuff I’ve got in git and stuff generated by shadow
if you are on 2.1.7+ there is currently a problem. I tested with 2.1.10 which seems to work
however it seems like https://github.com/Khan/aphrodite doesn’t work in 2.1.10
yeah this library isn’t like a big dependency for us, just wanted to let you know of a dependency that was working before that isn’t now (in case it affects others)
problem is that they I look for this pattern to decide if the file was ES6 converted by babel
I wonder if this is due to them using an old version of Babel (seems to be Babel 5): https://github.com/Khan/aphrodite/pull/281. Babel 6 might have changed this: https://babeljs.io/docs/plugins/transform-es2015-modules-commonjs/
might be but the detection was already questionable and I had to detect 3 different patterns already for the deps I had installed for testing
why is it that shadow has to do all of this detection? like, how does babel+webpack manage to use es6 import syntax at all times with every npm module. maybe i’m not thinking clearly but if they are doing some kind of detection, can we go peek at their code and see what they are doing?
actually the problem comes from the Closure Compiler and it wants to do the ES6/CJS interop
covering all the scenarios they describe is hard if the closure compiler has different ideas
for CLJS there isn't actually a problem if I revert it back to the way it was (without detection)
https://github.com/thheller/shadow-cljs-examples/blob/master/local-js/src/demo/foo.js
the answer to most of my “why is this so effing weird” questions in cljs is aways “because closure compiler” 🙂
closure compiler is actually how I'd expect things to work .. then there is stuff like aphrodite
which doesn't even make sense when you look at it 😛
there are too many ways of doing things in the JS world and they seem to be adding things every few months
i mean i know js is bizarre. but i still maintain that if cljs did its own symbol minification we could ditch closure compiler and have seamless integration with the js ecosystem.
well I wouldn't want to give up the :advanced
stuff Closure does and from what I can tell the JS world is working towards getting something comparable
I actually think they will converge on a set of standards at some point that will pretty much match what GCC does today
honestly if i can just get protorepl in atom working with shadow and maybe figure out a patch to get my linter working everything will be near perfect
question: the (:require ["npm-module-name" :as something])
is a really nice feature, but I wonder does it make sense to provide an option (maybe in :js-options
?) to use a synthetic namespace. i ask because right now the string messes up my linter and deviates from cljs. it’s nice to be able to require the right module name right from the source without a compiler option but in the final estimation not critical. just a thought.
don't tell anyone but (:require [npm-module-name :as something])
actually works as well
I just think a string is more reliable and makes it clear that you are importing JS and not CLJS
it dumps
java.io.FileNotFoundException: Could not locate seekeasy/handler__init.class or seekeasy/handler.clj on classpath., compiling:(seekeasy/repl.clj:1:1)
which i assume must be part of the repl protocol as i don’t have a handler.clj or a repl.clji’ve been looking for something that documents the repl/nrepl convention/protocol but haven’t found anything
the convention is to use middleware for tooling stuff but IIRC proto-repl just evals stuff
looking at the code, it seems to implement an nrepl connection. isn’t that all you need?