@bhauman I’m not sure how figwheel-main detects what is or isn’t on the classpath but it doesn’t really seem to work

I have aliases that provide :extra-paths and Figwheel doesn’t seem to know this

and complains about stuff that most definitely is on the classpath

@bhauman actually ignore what I said - it was working 😛

I was confused because I missed that Figwheel attempts to fix it

ah so I know what my issue actually is - @bhauman I don’t necessarily want src on the classpath

adding something I don’t want is actually problematic

i.e. src/cljs structure

Would it help in your case if figwheel compiled files lazily instead of eagerly processing all the cljs files on the classpath?

@dnolen yeah an option is needed to disable that behavior

but I normally only add "src" if your :main is in the "src" directory it would be helpful to know your specific case and which warning is getting printed

@bhauman my :main is in source but it’s not rooted at src

it rooted at src/cljs

so mucking with the classpath that I want is not desirable

Anyone running into this exception when trying to startup figwheel?

conductor.core> (require 'figwheel.main)
CompilerException java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V, compiling:(figwheel/main.cljc:1:1) 

@dnolen gotcha, will make an option, but its good to know that there is also a bug in my code because it should have added "src/cljs"

sorry not being clear

src/cljs does get added

the problem is if I set :path and I don’t include "src" intentionally

Figwheel messes up my classpath

So definitely going to make a switch

so you are adding a :main that is in cljs/src but you don't want it on your classpath

I can understand that

I would argue for not making a switch - but only fixing it if you can determine it was a actually mistake

let me show you something minimal so you can see what I mean

thanks

meanwhile I'm spending the day figuring out how to get a multi-domain HTTPs support running in an a letsencrypt world

@bhauman hrm, ignore what I’ve said for now - I can’t make it minimal - will hunt it down and put something together later

please when you get a chance, I'd love to understand

yes definitely will

@bhauman hrm I’m seeing some bizarre behavior - when I run figwheel it generates a target directory?

yes that happens

why?

I also see that it added target to the classpath

which I most definitely do not want

yeah that's part of the same behavior that I'll be making the flag for

if you don't have an output directory on the classpath figwheel can't server your assets

you can't add a classpath for a path that doesn't exist

and have it take affect for resources

:output-dir is specified in all cases

and "resources" is on every classpath

and :output-dir is always "resources/public/..."

and it's not though

the default :output-dir is "target/public"

what I mean is in my project

not somebody else’s project

so I don’t understand why I’m getting target

yes I get your meaning

you have and output-dir defined and there is no need to add one in that case

makes absolute sense

the end result for me is everything is getting completely messed up

and Figwheel is more or less ruining how tools deps is supposed to be used

tools-deps let’s me control the classpath finally

but Figwheel does all this stuff I do not want

its 3 different things, and they are there to help folks when they start out

I understand that

but it breaks tools-deps

I can no longer control the classpath

and I have push everything around

and files are compiling which shouldn’t etc. etc. etc.

yes this is not what I want

you are perhaps the first power user

and as that person you are helping me

sure but it’s also breaking a simple tutorial

where I want people to be able to run

clj -A:tut1 -m figwheel.main -b builds/tut1 -r

and then can just cycle through tutorials in one project

and that should be possible

so their understanding of tools deps will be completely obfuscated

so why not use the defaults?

for now

I'm happy to address these issues

ok - sure I have to refactor this into N different folders

and skip trying to explain how tools-deps solve very typical problems

you shouldn't have to?

w/o hoop-jumping

I don’t see how?

I can’t control the classpath

and can’t control what goes into the build

I understand completely now

source files with the same names changing incrementally

@dnolen there is a :target-dir option https://github.com/bhauman/figwheel-main/blob/master/doc/figwheel-main-options.md

I'm working on this problem now if you want to wait a beat.

wrong url

thanks, working on some slides now - let me know if it’s too much fiddling, I can split the directory structure if so

I did this way mostly so I could share the resources directory when serving (i.e. index.html / CSS) which aren’t changing

Is it possible to provide a default and override it if someone provides a :target-dir? I'm liking figwheel.main's out-of-the-box experience and defaults.

keeping artifacts out of "resources" makes cleanup simpler too

@john not sure I understand, I'm keeping the behavior and making a switch turn the helpfulness off

ah k, that's what I was wondering about

and @dnolen hmm it was using the :output-to to derive the target directory, changing it to :output-dir

not sure why it was generating an "target" directory

but almost done with the flag

k thanks again

also the code that was creating the source directory was naive in that it was creating the directory for the first source file with the :main ns it found. It should have checked the classpath first.

nah that was wrong it is checking the classpath first for the namespace and if it can't find it adds the classpath

yeah, that’s what I observed

and you’re treating src as a special case?

that’s what I can’t sort out

nope

k give me one second

not treating it as a special case

@bhauman https://github.com/swannodette/cljs-ess

just made this public

try clj -A:tut1 -m figwheel.main -b builds/tut1 -r

to see what I’m seeing

I could also very well be doing something stuipd

man you should have pointed me to this earlier

it wasn’t public, and I had remove a bunch of other problems first

cool, make the watch-path equivalent to the classpath

for each tutorial

that's the special case

is that why src gets added?

yes

ah k so that was counterintuitive

watch-paths = source-paths

yeah

so is that part of the metadata?

yeah you have it in each build file

:watch-paths

er

:watch-dirs

so this was my fault

sorry 🙂

watch-dirs

watch-dirs is equivalent to -w flag

which is also treated a source directory to pass to the compiler

so that's what was throwing you

so :watch-dirs must be explicitly supplied right?

yeah the classpath stuff was really a red-herring

actually it could be autodetected if your main is on your classpath

but its better to supply it explicitly

sanity regained

sorry for the runaround

no worries, it was helpful

@dnolen so no problem with the target directory?

or was that an outcome of trying different things to make it work

no it was exactly what you said, a missing build config

👍

also I'm always surprised that build files in directories work, as I never explicitly intended that