Fork me on GitHub
#boot
<
2015-10-07
>
malcolmsparks14:10:01

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

malcolmsparks14:10:31

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

malcolmsparks14:10:52

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

malcolmsparks14:10:16

while this:

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

malcolmsparks14:10:32

also copies over my assets

malcolmsparks14:10:41

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

malcolmsparks14:10:56

(as well as generating the .css I want)

malcolmsparks14:10:39

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"]
task is working

martinklepsch14:10:43

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

malcolmsparks15:10:03

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

assets/
, I want them to end up exactly as the same, in
target/
- I don't yet know how to accomplish that

malcolmsparks15:10:31

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

martinklepsch15:10:38

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

martinklepsch15:10:06

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

malcolmsparks15:10:28

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

martinklepsch15:10:08

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

malcolmsparks15:10:33

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?

martinklepsch15:10:42

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

martinklepsch15:10:57

(set-env :asset-paths [“assets“])
will basically cause something like cp assets/* target/

martinklepsch15:10:23

Does that make sense?

martinklepsch15:10:12

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

raywillig15:10:17

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

martinklepsch15:10:34

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

raywillig15:10:17

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

malcolmsparks15:10:31

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

martinklepsch15:10:47

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

malcolmsparks15:10:09

I mean, if I just have

(deftask build [] (comp))
then no assets get copied over

alandipert15:10:40

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

alandipert15:10:56

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

alandipert15:10:18

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

martinklepsch15:10:14

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

alandipert15:10:44

oh weird... so that should work

martinklepsch15:10:59

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

alandipert15:10:43

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

malcolmsparks15:10:37

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

malcolmsparks15:10:46

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

malcolmsparks15:10:18

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

malcolmsparks15:10:25

I'm still a boot newb

raywillig15:10:52

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

malcolmsparks15:10:15

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

malcolmsparks15:10:29

very mzero monadic simple_smile

malcolmsparks15:10:41

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 ! simple_smile

alandipert15:10:13

i'm lookin there too

alandipert15:10:35

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

martinklepsch15:10:43

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

martinklepsch15:10:15

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

malcolmsparks15:10:04

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

martinklepsch15:10:27

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

martinklepsch15:10:30

ah, wait. Should have read the docs more carefully simple_smile

alandipert16:10:18

we agree the real answer is a target task

alandipert16:10:38

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

micha16:10:02

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

alandipert16:10:29

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

alandipert16:10:52

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

alandipert16:10:04

ex boot build-jar target -d foo/bar

martinklepsch16:10:06

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

alandipert16:10:25

we were just discussing possible lifecycles of the target/ directory

alandipert16:10:40

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

juhoteperi16:10:55

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

alandipert16:10:36

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

alandipert16:10:22

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

juhoteperi16:10:55

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

alandipert16:10:45

ah, good to know

martinklepsch17:10:38

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

martinklepsch17:10:56

It’s about “the old boot"

alandipert17:10:16

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

martinklepsch17:10:16

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

alandipert17:10:40

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

donmullen17:10:08

@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.

jannis17:10:12

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.

jannis17:10:14

Any ideas?

jannis17:10:22

It seems like it's almost working.

jannis17:10:58

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

martinklepsch17:10:20

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

jannis17:10:33

Nope, before currently.

jannis17:10:51

@martinklepsch: Doh, swapping them did it!

martinklepsch17:10:50

@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 simple_smile

jannis17:10:14

Yeah, that makes a lot of sense.

jannis18:10:04

Ha, thanks. simple_smile 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")

pandeiro19:10:13

I think 30% is way too big fwiw

pandeiro19:10:20

re: HUD size

pandeiro19:10:35

that is not the place for an entire stacktrace

flyboarder19:10:50

@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

jannis19:10:05

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

micha19:10:38

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

micha19:10:57

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

jannis19:10:19

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

micha19:10:30

ah you can use the checkout task

micha19:10:48

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

micha19:10:20

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

micha19:10:40

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

micha19:10:52

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

jannis19:10:53

Ok, I'll try that

jannis20:10:02

Sweet, that worked fine

martinklepsch20:10:29

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

pandeiro20:10:04

@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

pandeiro20:10:15

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

pandeiro20:10:22

I think a constant height is preferable

pandeiro20:10:33

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

martinklepsch20:10:09

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

martinklepsch20:10:09

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.

pandeiro20:10:34

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

pandeiro20:10:45

Especially considering the lack of an 'X' button

pandeiro20:10:06

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

pandeiro20:10:15

Just food for thought

pandeiro20:10:28

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

juhoteperi20:10:56

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

pandeiro20:10:05

ah ok, could be

pandeiro20:10:12

the close button is maybe most important of all

pandeiro20:10:29

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

juhoteperi20:10:31

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

pandeiro20:10:49

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

juhoteperi20:10:07

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

pandeiro20:10:22

ah ok, for me it does not replace the console

pandeiro20:10:26

it is a quick visual cue

pandeiro20:10:55

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

pandeiro20:10:02

ie, any reason not to?

juhoteperi20:10:28

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

pandeiro20:10:43

oh that would be very cool

juhoteperi20:10:43

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

pandeiro20:10:09

do you think the figwheel code is definitely usable?

martinklepsch20:10:27

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

pandeiro20:10:41

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

micha20:10:04

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

micha20:10:32

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

juhoteperi20:10:33

@micha: Figwheel has options for that

juhoteperi20:10:46

We can just make on-jsload to set correct option

micha20:10:05

i mean without specifying any options to boot-reload

juhoteperi20:10:27

like the jQuery event?

micha20:10:29

there's no harm in sending a custom event

micha20:10:36

or something

juhoteperi20:10:47

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

juhoteperi20:10:51

No harm in it either

micha20:10:02

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

micha20:10:09

which is pretty nice

micha20:10:27

i would prefer not to require boilerplate arguments to reload

martinklepsch20:10:00

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

juhoteperi20:10:14

@martinklepsch: No need to duplicate complex file reloading stuff

juhoteperi20:10:02

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

juhoteperi20:10:19

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

martinklepsch20:10:29

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

juhoteperi20:10:10

But I'll clean Figwheels code where possible

martinklepsch20:10:25

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

juhoteperi20:10:32

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

juhoteperi20:10:49

and some corner cases

micha20:10:59

boot-cljs doesn't compute dependency order properly?

martinklepsch20:10:12

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

micha20:10:16

whoa, what's it doing wrong?

juhoteperi20:10:51

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

juhoteperi20:10:16

@martinklepsch: No functionality, only the data about it

micha20:10:42

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

micha20:10:50

we get that info in the compiler for sure

juhoteperi20:10:03

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

micha20:10:13

i was using the compiler env

micha20:10:22

did you remove that?

micha20:10:42

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

juhoteperi20:10:51

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

juhoteperi20:10:08

I would instead add namespace and requires metadata to files

micha20:10:20

yes that too

micha20:10:35

the dependency ordering thing was a temporary thing kinda

micha20:10:50

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

micha20:10:14

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

micha20:10:17

that's the key thing

micha20:10:37

you can uild powerful tooling on that

juhoteperi20:10:03

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

micha20:10:34

i'm sure there is

micha20:10:38

testing comes to mind

micha20:10:53

module optimization perhaps

juhoteperi20:10:05

module optimizations is already done by Cljs

micha20:10:13

automatically?

micha20:10:23

like it figures out how to split the modules?

juhoteperi20:10:25

As automatically as it can be done

juhoteperi20:10:51

You define the modules and main namespaces for each

micha20:10:56

i think it can be completely automatic

micha20:10:13

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

micha20:10:25

you can then compute the optimal module partition

micha20:10:01

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

micha20:10:13

it would be nice to experiment with a separate gcl task

juhoteperi20:10:21

That would require huge changes to Cljs

micha20:10:21

to do optimizations and things

micha20:10:30

you can run cljs compiler in none mode

micha20:10:36

and then optimize yourself separately

martinklepsch20:10:42

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

juhoteperi20:10:01

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

micha20:10:17

yeah so that can still be used

micha20:10:31

you can still call those functions and stuff

micha20:10:36

just from a separate task

micha20:10:44

with other processing in the middle

juhoteperi20:10:27

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

micha20:10:57

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

micha20:10:04

but anyway, that's a use case

micha20:10:34

there are undoubtedly others

juhoteperi20:10:42

this should allow everything that Closure compiler does

micha20:10:49

it allows it yes

micha20:10:58

but you need to add your own boilerplate

micha20:10:05

which i do not enjoy

juhoteperi20:10:10

Ah, for module loading?

micha20:10:20

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

micha20:10:33

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

micha20:10:44

because it involves multiple builds and deployment issues etc

micha20:10:11

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

micha20:10:14

automatically

micha20:10:35

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

micha20:10:56

yeah like with hoplon we could automate the entire thing

micha20:10:11

you'd never need to specify anything

micha20:10:22

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

juhoteperi20:10:32

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

micha20:10:43

yeah it would need to do two passes though

micha20:10:47

once with :none

micha20:10:53

to get the analysis info

micha20:10:58

then again to do the thing

juhoteperi20:10:16

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

micha20:10:24

you don't want that

micha20:10:40

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

micha20:10:55

so you need to allocate namespaces to modules

juhoteperi20:10:13

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

micha20:10:24

yes, and it will continue to do that

micha20:10:29

but that file will be very small

micha20:10:34

it will just be a js shim

micha20:10:38

that loads the modules

micha20:10:55

the modules will be shared and cached in the browser presulably

micha20:10:36

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

martinklepsch20:10:05

@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.

juhoteperi20:10:33

Note about SASS errors etc. is good.