Fork me on GitHub
#figwheel-main
<
2018-09-21
>
gas00:09:54

just seen @shaun-mahood intergrant startup -will use that, cheers

benzap03:09:45

I don't think this is figwheel specific, is there documentation on how you can go about pulling in node dependencies?

rgm03:09:43

@benzap I’m having a lot of luck with these approaches … either https://clojurescript.org/guides/webpack or shadow-cljs https://github.com/thheller/shadow-cljs … it’s still early days on the cljs compiler :npm-deps stuff (https://cljs.github.io/api/compiler-options/npm-deps) so probably better to delegate to webpack or shadow if you’re just starting out

👍 4
bhauman10:09:36

@benzap I recommend learning/using the webpack approach with figwheel-main https://clojurescript.org/guides/webpack

👍 4
bhauman10:09:43

and figwheel-main has an option :npm option to help you with some of the boilerplate https://figwheel.org/config-options#npm

stathissideris12:09:17

excuse my ignorance, but is npm only useful for node apps or is it generally useful for consuming dependencies for browser clojurescript?

dnolen13:09:42

used for both cases

🙂 4
shaun-mahood17:09:18

I'm a little unclear on how to use the compiler options on https://figwheel.org/docs/compile_config.html Running lein run -m figwheel.main -- -h, it seems like I can link a compile-options edn file using -co, and using the scripting API with the`:options` key. Is there a way to include the compiler options in a [[build-name]].cljs.edn file?

pesterhazy20:09:24

@shaun-mahood -co file.cljs.edn should work same as -co '{:foo :bar}'

shaun-mahood20:09:34

@pesterhazy Yes, that part is working fine - I'm wondering if there's a way to include the cljs compiler options directly in the same edn file that my figwheel build is using

shaun-mahood20:09:26

Something like this

^{:mode :build-once}
{:main          project.main
 :optimizations :advanced
 :output-to     "resources/public/js/main.js"}
(which isn't working for me)

benzap21:09:46

Can anyone confirm if failing compilation builds produce a non-zero return value on the commandline? I have a makefile which continues onto the next build step after running a failing compilation ex.

benzap21:09:01

I'll test some more, maybe having them as dependency targets is messing it up

benzap21:09:35

I can confirm that it's producing a 0 return code, when I think it should be producing a non-zero error code when the compilation fails

Garrett Hopper22:09:09

@bhauman, I should be able to use :closure-defines in the :options to figwheel.main.api/start and expect to be able to evaluate the symbol of the define and not get the default value, right?

Garrett Hopper23:09:58

I got it figured out over on #clojurescript. 🙂 I didn't have the namespace for the name.

bhauman23:09:10

cool cool 🙂

bhauman23:09:31

@shaun-mahood what command are you trying to execute?

bhauman23:09:57

also I think you mean figwheel options not compiler options?

bhauman23:09:48

the figwheel options are picked up from -co but the final behavior is highly dependent on the main option you provide

bhauman23:09:32

in the case of build once it is probably being overridden

bhauman23:09:02

are you trying to start a REPL without a watcher?

bhauman23:09:09

@benzap what is the compile command?

benzap04:09:14

I was calling make build, which calls :build-prod-ui

benzap04:09:09

the result of which calls clj -A:build-prod-ui -R:deps-ui

benzap04:09:42

it was failing (isn't anymore) and it was throwing a return code of 0, when I think it should have been throwing a non-zero return code

benzap04:09:05

this was in 0.1.9-SNAPSHOT

benzap16:09:35

@bhauman do you want me to isolate the issue into something more succinct and file an issue on github? Would add some clarity.

bhauman16:09:47

I just needed to know what the main-opt was

bhauman16:09:10

so it was -bo that wasn’t behaving correctly

benzap16:09:43

ah ok great 👍

bhauman23:09:26

figwheel.main -c my.namespace ?

bhauman23:09:47

yeah this is probably a bug

shaun-mahood23:09:44

@bhauman I can get the compile options working with co and by using the scripting api directly, mainly was wondering if there’s a way to define them directly in my dev.cljs.edn. I think it would help me consolidate a few things between my dev and uberjar builds, but also trying to understand how they relate a bit better.

bhauman23:09:36

@shaun-mahood when you say compile options what do you mean specificly?

bhauman23:09:02

clojurescript compiler options or figwheel options?

shaun-mahood23:09:42

Clojurescript compiler

bhauman23:09:58

but that is the main content of dev.cljs.edn ??

bhauman23:09:15

dev.cljs.edn holds the compiler options

bhauman23:09:02

this is why I’m confused

shaun-mahood23:09:38

Ok, for whatever reason that wasn’t clear originally - I realized that I missed that a while ago but when I tried them in there they weren’t working for me and thought I must have misunderstood somethin else.

bhauman23:09:39

yes the cljs.edn file is just a compiler options map

shaun-mahood23:09:13

In the snippet I posted above, can you see anything clearly wrong to put in a .cljs.edn file? If not then I must have something else messed up, since it will take the figwheel options but not the cljs compiler ones

bhauman23:09:16

if the options weren’t getting picked up then that may be a bug

bhauman23:09:38

@shaun-mahood it depends on the full command that you were sending