I'm still a bit confused as to when resources or assets are copied into the target directory

`clojure

clojure
(deftask dev
  "Simple alias to run application in development mode"
  []
  (set-env! :target-path "target")
  (comp
   (serve :dir "target/dev")
   (watch)
   (speak)
   ))

this results in an empty target directory, which I'm fine with

while this:

clojure
(comp
   (serve :dir "target/dev")
   (sass :sass-file "app.scss"
         :output-dir "."
         :line-numbers true
         :source-maps true)
   (watch)
   (speak)
   )

also copies over my assets

(set-env!  :asset-paths #{"assets"})

(as well as generating the .css I want)

what's the idiomatic way of telling boot to copy assets over to the target directory? perhaps there's a side-effect of the way the sass

[mathias/boot-sassc "0.1.5" :scope "test"]

hi @malcolmsparks

I think the best reference is this: https://github.com/boot-clj/boot/wiki/Filesets#fileset-components

@malcolmsparks: There’s a default target for :target-path (just fyi)

I'm still a bit confused. I've got some files in

assets/

target/

I sort of get the idea about the input/output file types though

so you want to do something like cp -r assets target/assets ?

yeah

do you have a directory that you list in :resource-paths?

ah, no, I only list it in :asset-paths

well, unless you want to process the files somehow :asset-paths would be ok too

do I need to specify some task in the comp to get them to be copied over? or would you expect that to happen by default?

you just need to be aware that the contents of the directories that you add to those *-paths things are added to the fileset not the directory itself

(set-env :asset-paths [“assets“])

Does that make sense?

(And there’s no extra task required to have files copied over if they are in :resource-paths or :asset-paths)

@martinklepsch: @malcolmsparks Also, IIRC the files are not actually copied to target-path until the taks ends. is that the case?

things are synced at the end of the pipeline or at the end of “a watch loop"

oh so even with a watch task in the pipeline the files will end up in target

?

hmm. If I have 0 tasks, nothing gets copied over. It's the inclusion of the sass task that triggers the asset copy it seems

That’s how (serve :dir “target”) works if you use it with watch (ideally you serve from classpath though IMO).

I mean, if I just have

(deftask build [] (comp))

@malcolmsparks: identity is the "null" task, maybe that's what you want?

e.g. (deftask build [] identity) should cause assets to appear in target

which you could also write as (def build (constantly identity))

@alandipert: (= (comp) identity) ;=> true

oh weird... so that should work

Null task is covered here https://github.com/boot-clj/boot/wiki/Tasks#the-null-task but tbh I’m equally surprised and would have expected something to show up in :target-path

wow that wiki page has gotten a lot better since i last looked at it

> (deftask build [] identity)` should cause assets to appear in target

that's what I was expecting too - so I'm confused why it isn't working

it does appear to work but only if I add back the 'sass' task, and I was trying to determine whether it was something weird in the sass task itself, but couldn't find anything

I'm still a boot newb

i remember some discussion about that but i don't remember what the trigger was supposed to be, but the idea was that something like boot by itself wouldn't cause target to be populated

@alandipert: but I still appreciate your point, I remember when I first realized that (comp) was identity, and (+) was 0, and (*) was 1

very mzero monadic

so I guess I'll just put the sass thing back and accept that this also triggers the boot assets copy, but I'd love to know if there's a more benign trigger that doesn't require a scss file to work !

i'm lookin there too

I think the issue is that there’s no difference and thus nothing is synced: https://github.com/boot-clj/boot/blob/8b6ebea81e06d4e76e9e6ac23896c21e1e5b68ad/boot/core/src/boot/core.clj#L690

i thought that also, but did see assets via show -f in my test project

They are in the fileset, but the (seq (output-files diff)) returns nil I guess

as soon as you have one task that changes something it will return something and then sync everything

(that definitely concurs with what I'm seeing in my project)

I’m wondering, can I change boot.core/sync-target without rebuilding boot itself? Like some alter-var-root black magic?

ah, wait. Should have read the docs more carefully

@martinklepsch: been discussing with @micha

we agree the real answer is a target task

ideally the user decides what to do with the last fileset, not boot

yeah it's just another task whcih you can use or not use

we find ourselves using boot as much as an app container as a build tool

running boot serve in Docker vs. boot build-jar, really two different use cases

ex boot build-jar target -d foo/bar

In what context was a target task also considered again? some cljs stuff?

we were just discussing possible lifecycles of the target/ directory

should it only exist while boot is running? should it not exist while boot is running? etc

Also when we were wondering if it's writing to target dir which is causing fileset overhead

@juhoteperi: you mean it would be nice to not have to write to target?

i wish we'd known boot wasn't a build tool earlier

@alandipert: We tried it and it didn't have any effect on performance

ah, good to know

Just stumbled upon this one while skimming issues: https://github.com/boot-clj/boot/issues/286 /cc @alandipert

It’s about “the old boot"

oh thanks, i have him on gchat - will reach out

Would be good to also close the issue at some point 🐵

@micha: @alandipert do you still use http://waffle.io actively?

@martinklepsch: thanks for digging into the issue and making that ticket. i don't think we use it actively, @micha could confirm

@martinklepsch: I really liked http://waffle.io when we used it at a previous company — don’t use it now as we’re using Bitbucket instead of github.

Hey folks! I can't get the browser repl to work for some reason. I've included cljs-repl in the build pipeline for my app. It seems to be starting a cljs repl at a random port (e.g. 55317). I'm serving the app with boot-http and I can see it open a websocket for that port. However, I can't open a REPL with "boot repl -c" followed by "(start-repl)". The latter simply starts another cljs-repl on <ws://127.0.0.1:0>, drops me in a "cljs.user=>" prompt. Everything I then type in results in this: java.io.IOException: No client connected to Websocket.

Any ideas?

It seems like it's almost working.

Oh, actually, that random port is the reload server socket, not cljs-repl. So it's not working at all.

@jannis: are you running the cljs-repl task before the cljs task?

Nope, before currently.

@martinklepsch: Doh, swapping them did it!

@jannis: The cljs-repl task is injecting some client code into the cljs build, so if the order is wrong the client code won’t be in the build

Yeah, that makes a lot of sense.

Cheers

Have fun

Ha, thanks. I haven't used a browser repl before. Now I need to figure out how to access any of my CLJS code and do things more useful than (js/alert "Hello")

I think 30% is way too big fwiw

re: HUD size

that is not the place for an entire stacktrace

@pandeiro: agreen the full stack trace should go else where, i was looking into how the boot-reload file inject things into the cljs build, a tool like symphony profiler would be nice

What's a good way to include some dependency (om in this case) from git with boot?

@jannis: how do you mean "from git"?

om is distributed via Clojars maven repo, isn't it?

Yes but I want to play with the latest code from master

ah you can use the checkout task

the idea is to install the latest om into your local maven repo

usually the latest code from master needs to be processed in some way before your program can use it

so the best and simplest way is to build the jar locally and install it in your local maven repo

then you can just add that new version to your project dependencies

Ok, I'll try that

Sweet, that worked fine

🍻

Thanks

@pandeiro: It’s only ever that big when there is a lot of stuff right?

@martinklepsch: not sure, i've never seen it more than one line; i was just going by the recent discussions and the recent suggestion to use 30vh

If that's a max-height then yeah, I guess...

I think a constant height is preferable

show one warning and add "and 15 more warnings..."

@pandeiro: can you think of a case where you have 15 warnings that are not the result of some sort of cascade?

I agree that maybe there are smarter ways to handle this but I’m thinking if there’s so much stuff you probably messed up anyways and will fix all warnings at once.

Sure... but I think covering a huge part of the screen is way too obtrusive

Especially considering the lack of an 'X' button

And I also never recall seeing the Figwheel HUD cover a large portion of the screen (but I could be wrong about that)

Just food for thought

Another idea is that boot-reload could have a flag to disable the HUD

IIRC figwheel HUD can cover the whole screen but has close button

ah ok, could be

the close button is maybe most important of all

you may want to inspect some browser state before running another compilation cycle

And I think that is the best way, because I sometimes have like 200 warnings when refactoring something and I want to see them all

@juhoteperi: those warnings would show up in your console too though right?

@pandeiro: But the idea of HUD is that I don't need console

ah ok, for me it does not replace the console

it is a quick visual cue

but yeah i can understand that... an 'X' button should be easy enough -- should I do that?

ie, any reason not to?

Some future boot-reload will drop our own client and use Figwheel code

oh that would be very cool

If you need the close button now, do it, but if you are not in a hurry we'll get it for free in few weeks

do you think the figwheel code is definitely usable?

Yes, I did a quick test already: https://github.com/adzerk-oss/boot-reload/compare/figwheel

Cool to see that some stuff from figwheel is usable after all.

sweet, that is great then. i can wait for that.

@juhoteperi: the only thing i would want would be to still fire some kind of event on the document when a reload event occurs

that's better for some things than --on-jsload because it's open and the task option is closed

@micha: Figwheel has options for that

ok cool

We can just make on-jsload to set correct option

i mean without specifying any options to boot-reload

like the jQuery event?

there's no harm in sending a custom event

yeah

or something

We could do it, though I don't see why boot-reload should care about that

No harm in it either

yeah i have stuff in hoplon to set it all up automatically

which is pretty nice

i would prefer not to require boilerplate arguments to reload

@juhoteperi: what’s the rationale for using figwheel’s client in general?

@martinklepsch: No need to duplicate complex file reloading stuff

And better for community to not put effort into two implementations doing the same

I plan on contributing some parts from our current implementation to Figwheel when I have time

I feel like the code we’re replacing with figwheel.client looks much easier to maintain than fw's

Yes

But I'll clean Figwheels code where possible

What’s the complex part about the file reloading? Maybe that’s something that could be put into a separate lib with a sane API and reused from FW & boot-reload

Dependency ordering and filtering out namespaces which can't be reloaded

and some corner cases

boot-cljs doesn't compute dependency order properly?

@micha: No

that’s done by closure no? (via some private api)

whoa, what's it doing wrong?

@micha: It only orders Clojurescript namespaces, not Closure or foreign-libs

@martinklepsch: No functionality, only the data about it

deraen: that's a bug then, because it should be doing that

we get that info in the compiler for sure

@micha: It's not available in public CLJS api

i was using the compiler env

did you remove that?

Yes

ah

it's valuable to have that information in the fileset though

Doesn't matter too much, I have not noticed any problems

I would instead add namespace and requires metadata to files

yes that too

the dependency ordering thing was a temporary thing kinda

but having true analysis info in the fileset meta would be ideal

info about what the compiled js files are and how they relate to other compiled js files

that's the key thing

you can uild powerful tooling on that

*build

Is there any other case for that data besides boot-reload?

i'm sure there is

testing comes to mind

module optimization perhaps

module optimizations is already done by Cljs

automatically?

like it figures out how to split the modules?

As automatically as it can be done

You define the modules and main namespaces for each

i think it can be completely automatic

if you know the dependencies of the various files and you have .cljs.edn info

you can then compute the optimal module partition

and gcl compiler doesn't need to be complected with clojurescript compilation imo

it would be nice to experiment with a separate gcl task

That would require huge changes to Cljs

to do optimizations and things

you can run cljs compiler in none mode

and then optimize yourself separately

I’m pretty sure the Closure module splitting stuff is pretty good

Yes but Cljs is doing plenty of bootstrapping for Closure compiler in advanced mode that it doesn't do in none mode

yeah so that can still be used

you can still call those functions and stuff

just from a separate task

with other processing in the middle

Would be quite complicated and I doubt it's something that would be exposed on the API

yeah i'm sure it's not on the API

but anyway, that's a use case

https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules

there are undoubtedly others

this should allow everything that Closure compiler does

it allows it yes

but you need to add your own boilerplate

which i do not enjoy

Ah, for module loading?

i'd prefer to have the computer figure it out on its own

which is a concern that goes beyond what the cljs compiler shouldbe doing

because it involves multiple builds and deployment issues etc

so like if you're compiling multiple builds the cljs task should just make the optimal module configuration for you

automatically

it's not like there isn't an optimal solution

yeah like with hoplon we could automate the entire thing

you'd never need to specify anything

and you'd just get the best allocation of modules and whatnot

For hoplon, you could have a task that builds the configuration map automatically

yeah it would need to do two passes though

once with :none

to get the analysis info

then again to do the thing

It could just create a module from every hoplon page(?)?

you don't want that

you want the minimum number of script files to load in the html page

so you need to allocate namespaces to modules

Doesn't it currently create completely separate js file for each page?

yes, and it will continue to do that

but that file will be very small

it will just be a js shim

that loads the modules

the modules will be shared and cached in the browser presulably

i guess i just have to do it and stop talking about it

@juhoteperi: ^ created the issue to further discuss. I’m not yet 100% convinced it’s the right step but that doesn’t have to hold you back of course.

Note about SASS errors etc. is good.