Fork me on GitHub
#boot
<
2016-05-30
>
onetom00:05:54

@mynomoto: you mean showing project/ns info in the output of boot -h?

mynomoto00:05:33

@onetom: yeah, that's what I'm thinking. Also for boot task -h but boot -h seems more helpful specially when there are some :refer :all on build.boot

onetom00:05:24

@juhoteperi: sure, I remember listening on a random port with boot-http was an issue for me at the beginning. With Datomic however I can have a singleton connection and fork it further for the individual tests with the datomock lib and thanks for confirming my worries!

onetom05:05:03

im trying to use this new boot-maven-interop approach, so 1. there is only a single source of truth about the dependencies 2. intellij understands where those dependencies are and provides code navigation 3. i have autocompletion for specifying dependencies this all works but then how can i get a repl? if i start boot repl i get .nrepl-port file but to utilize it i would need to create a Remote REPL in IntelliJ with the Use Leiningen REPL port option. it doesn't seem to work however, because I don't have a project.clj... 😕

onetom05:05:36

ok, i tried it on a "from scratch" project and it worked there... 😕 the problem was probably not specifying clojure as an explicit dependency

juhoteperi06:05:06

@onetom: Boot-alt-test has option to disable parallel tests

micha12:05:05

@onetom: i think you always want to specify a clojure dependency

micha12:05:23

because everything depends on clojure

micha12:05:43

and usually the earliest compatible version, which end up not being what you want

micha12:05:11

so it's kind of random which transitive clojure you get

micha12:05:37

the explicit clojure dep fixes that

onetom13:05:27

sure, it was just confusing that boot repl worked but couldn't connect to it from intellij...

onetom13:05:48

although that was not the problem at the end, but we couldn't track it down what it was exactly. just recreated the intellij project and it was okay then...

lucien.knechtli21:05:31

does anyone know how to get foundation sass to work with boot-sass? Adding [org.webjars.bower/foundation-sites "6.2.1"] to my depenencies doesn't give me any errors other than an empty css file with foundation comments at the top when I do @import "foundation-sites/scss/foundation"

micha21:05:29

@lucien.knechtli: you may need to use the sift task to dump that dependency into the fileset

micha22:05:24

i'm not sure but it may be that they need to be files on disk rather than jar resources on the classpath for the sass compiler to pick them up

lucien.knechtli22:05:02

according to boot-sass, it should pick it up from the jar resources

lucien.knechtli22:05:25

Resource META-INF/resources/webjars/{package}/{version}/{path} can be referred using {package}/{path}
E.g. bootstrap/scss/bootstrap.scss => META-INF/resources/webjars/bootstrap/4.0.0-alpha/scss/bootstrap.scss
on the github

micha22:05:32

see the -j,--add-jar option (do boot sift -h at the command line or (doc sift) at the repl

lucien.knechtli22:05:04

and it seems to be, to a limited extent. the compiled css file has comments from foundation.scss

lucien.knechtli22:05:27

it just doesn't seem to be importing anything from the files that foundation.scss imports

micha22:05:24

you could still try unpacking the jar and see if that fixes it

micha22:05:45

then you will have identified the issue with a good reproduction case to fix the bug

lucien.knechtli22:05:27

when I put the actual sass file structure with my sass files, then I get a bunch of errors that look like it isn't processing relative references

micha22:05:08

try boot show -p and look for dependency conflicts

micha22:05:13

and boot show -d

lucien.knechtli22:05:15

for ex: in util/util.scss, @import 'unit'; says it can't find unit, which is in util/unit.scss

lucien.knechtli22:05:50

no dependency conflicts

micha22:05:56

looks like you need the extension, maybe

micha22:05:05

like @import 'unit.scss';

lucien.knechtli22:05:21

that's in foundation's sass code though

lucien.knechtli22:05:26

shouldn't need to modify that..

lucien.knechtli22:05:43

Loading order for @import "{name}"; on file at {path}

Local file at {path}/{name}.sass or {path}/{name}.scss

lucien.knechtli22:05:52

that says otherwise

lucien.knechtli22:05:09

think extension is just for webjar assets

lucien.knechtli22:05:14

i'll try changing that

micha22:05:16

i'm out of ideas 🙂

micha22:05:31

certainly is troublesome if you get unrelated errors when you explode the jar in to the fileset

micha22:05:39

indicates someting else is going on

lucien.knechtli22:05:09

the errors look like when it's in the fileset, it isn't respecting relative file paths

lucien.knechtli22:05:42

since if I change it to use the full filepath within the css directory, that error goes away and it shows another

lucien.knechtli22:05:57

but it doesn't show any errors when using the webjar 😕

lucien.knechtli22:05:13

oh wait nvm... it's showing the same errors

lucien.knechtli22:05:16

nvm again. that was the _settings.scss file not having the right import.

lucien.knechtli22:05:10

hmm using the bootstrap example seems to work...

lucien.knechtli22:05:42

guess I know why bootstrap works and foundation doesn't - boostrap has all its scss files in one folder, while foundation uses a file heirarchy

lucien.knechtli22:05:04

and relative file paths apparently don't work with boot-sass

richiardiandrea22:05:31

ah, good to know

richiardiandrea22:05:52

but probably it is an easy patch to boot-sass

lucien.knechtli22:05:40

well there's been an issue open on it since 2014 i think