Fork me on GitHub
#clojurescript
<
2018-10-23
>
attentive01:10:38

Anyone got any advice on preventing cljsbuild from compiling certain source paths?

attentive01:10:11

I have the following in my build configuration:

{:id           "dev-billygoat"
                         :source-paths ["src/billygoat/cljs"]
                         :figwheel true
                         :compiler     {:main                 billygoat.core
                                        :output-to            "resources/public/billygoat.js"
                                        :output-dir           "resources/public/out"
                                        :asset-path           "out"
                                        :source-map-timestamp true
                                        :verbose true}

attentive01:10:33

The thing that's troubling me is that eg lein cljsbuild once dev-billygoat picks up files for another part of my project, from src/reagent, and overwrites part of the Reagent namespace when I'd like that not to happen.

attentive01:10:22

Tried a couple of things but it feels like there's a bit too much "magic" happening in source path resolution.

bhauman01:10:41

@attentive cljsbuild adds all the source paths from all the builds to the classpath, if you want to use cljsbuild you will need to not have one namespace that does different things

4
attentive01:10:19

Yes, I'm just figuring that out—I've never really tried to get it to do a bunch of orthogonal builds in one repo before

attentive01:10:03

(the src/reagent directory contains shim redefinitions of core Reagent stuff for React Native, but I'm trying to package a vanilla Reagent application in the app as a WebView)

bhauman01:10:51

you can try to use leiningen profiles so that all teh paths aren’t in the project map at the same time

attentive01:10:43

Yeah, I'm attempting that—I think if I move the src/reagent stuff to my React Native source paths (which have their own profile(s)), that may work—I think it's being included in both builds as part of a general principle of resolving deps via any local overrides (which is fine)

attentive07:10:15

Ended up resolving these issues with two main insights: 1. The shim/override code in src/reagent could be moved to env/reagent_shim/reagent and "env/reagent_shim" could be added to :source-paths for the applicable profiles, whereas for the others it would be unused. 2. I had to do a yarn add @cljs-oss/module-deps due to some not entirely scrutable build error.

andy.fingerhut02:10:58

@mfikes Please, don't let your life be completed by this - enjoy and hack on! https://github.com/jafingerhut/clojure/tree/undefined-behavior

mfikes02:10:13

@andy.fingerhut Hah! That's awesome!

andy.fingerhut02:10:33

Dude, I am totally going to pimp this out.

parrot 16
andy.fingerhut02:10:46

Several more URLs I can think of.

frenata02:10:18

great stuff, now I just need to compile this into a jar, drop it in a coworker's .m2 in place of the official clojure, and wait...

aisamu11:10:08

Is it possible to use npm modules required through :npm-deps in js modules? Things work as expected with webpack bundling, but we don't have the nice GCC optimizations there. Here's what'd work in my imaginary world:

build.edn:
  ...
  :npm-deps {:react "16.5.2" ...
  :foreign-libs {:file "src/js/components"
                 :module-type :es6} ...

src/js/components/some_component.js:
  import React from "react";
  ... React.createElement( ...

dnolen14:10:20

@aisamu GCC optimizations cannot work in general for JS libraries since they were not written with Closure mind

aisamu14:10:33

Thanks! If I own the JS code, can I write it in a way that makes it possible to go through GCC (via :foreign-libs js modules) and use the provided :npm-deps?

dnolen16:10:05

you don’t need :npm-deps if you’re just going to write some JS

aisamu16:10:24

Mix of JS and CLJS. Ran into this trying to share "react" between reagent and JS components. Works OK with webpack bundle - just trying to adopt :npm-deps.

dnolen17:10:47

:npm-deps should be considered experimental and advanced

dnolen17:10:00

it’s not recommended unless you have a lot of expertise and a lot of patience

☝️ 4
aisamu17:10:47

Got it, thanks!

dnolen14:10:27

ClojureScript has it easier since we generate code for you

artur19:10:39

Is there a better way to add conditional style names?

lukas.rychtecky06:10:02

You can do (clojure.string/join " " (concat ["list-header"] (when pred? "red"))) or you can you a util function for it like https://github.com/druids/ccn#css-class

tavistock19:10:10

newer versions of reagent allow a vector of strings

artur19:10:49

I am using 0.6.1

tavistock19:10:22

I never found a better way, you could write a function that does it or update

artur19:10:27

So I presume I use when-let to conj another one if current-items is greater than 3?

tavistock19:10:58

you coud use cond->

artur19:10:06

It's not a biggie, jsut thought about asking if there might be a better way

tavistock19:10:15

(cond-> "list-header" (> (count current-items) 3) (str " red"))

jthibaudeau19:10:58

I think using cond-> with many conditions would result in a lot of extra str calls

tavistock19:10:20

it seems like they just want a more readable way of doing their classes

dnolen19:10:25

I prefer the cond->

dnolen19:10:35

I don’t think you should be worrying about extra str calls

dnolen19:10:58

that’s not going to show up meaningfully in any profile of a React application

jthibaudeau19:10:20

@tavistock the class vector of strings/keywords is pretty nice IMO, didn't know that worked