Fork me on GitHub
#hoplon
<
2016-11-05
>
jumblerg08:11:39

@alandipert, @micha: we really should have a js or clojure task for our client-side code that is roughly equivalent to javac on the jvm, and allows the user to have javascript and clojure sources in a project together. of course, there would be some differences due to javascript's super-special approach to dependency management and the fact that the closure compiler is the backend for the clojure compiler. the ideal way to do this probably involves splitting up boot-cljs and factoring out the closure compiler into a separate task...

thedavidmeister12:11:27

@dm3 hey, how do i override on!?

thedavidmeister12:11:46

this when-dom thing is really causing me problems 😞

dm312:11:47

I'd think a defmethod would just ovveride

thedavidmeister12:11:59

don’t think i’ve done that before

thedavidmeister12:11:02

i’ll have a look

jumblerg13:11:57

@micha: looks like the ns+ macro is discarding javascript deps

jumblerg13:11:26

when i look at the output after the hoplon task has run, they're not in the generated ns form

micha13:11:46

interesting

micha13:11:12

yeah that's another special case to add

micha13:11:11

you can add js to a project the hacky way via the :prelude cljs compiler option

micha13:11:35

that just prepends files to the compiled js

micha13:11:12

only works with optimization modes that produce one js output file

micha13:11:22

ie not :none

jumblerg13:11:51

yeah. so boot-hoplon needs to: 1. ignore the illegally-formed deps.cljs files and 2. pass through required javascript dependencies

micha13:11:58

or you can paste the js source into a cljs namespace

micha13:11:06

and evaluation the string

micha13:11:15

eval the string

jumblerg13:11:06

i'm really missing inc.js files right now.

micha13:11:26

they're bad in the long run though

jumblerg13:11:30

yeah, i get it

micha13:11:52

so making infrastructure for it is counter productive

jumblerg13:11:05

i do think we should have a js task or something like it where we pass in a manifest of the stuff that is in the deps.cljs file.

micha13:11:16

we should spend the same effort to automate the right way

jumblerg13:11:27

much cleaner and more intuitive.

micha13:11:53

making the jar for the js dependency is the right way i think

jumblerg13:11:15

as opposed to having javascript sources as part of a project?

jumblerg13:11:45

let's say part of your application is written in cljs, but the other part in js

jumblerg13:11:16

from a cohesive standpoint, i want both of these in my sources, just like i can with clojure and java files.

micha13:11:49

applications and libraries are different

jumblerg13:11:04

maybe i want to optimize part of my app while writing it in js, or maybe i inherited an app that was written in js and i'm refactoring it to clojure (like i am now).

micha13:11:14

if you have js in a cljs application is going to be library code

jumblerg13:11:21

right, for libs, this totally makes sense.

micha13:11:50

js in a cljs application is always library code

micha13:11:59

like i said you can make a cljs namespace that just evals a js string

micha13:11:09

in your project

micha13:11:27

that's essentially what the deps.cljs does

micha13:11:53

when you require that namespace the js code runs

jumblerg13:11:58

but why does it need to be? since these files are leaves of the dependency tree since they're part of an app and not a lib, and all belong to the same artifact, why couldn't there simply be a manifest file passed as an argument to a js task.

micha13:11:23

that is what deps.cljs is

jumblerg13:11:49

so in theory, if this wasn't a special case that upset boot-hoplon - and ns+ was happy with javascript deps - adding deps.cljs to the classpath would work.

micha13:11:52

have you verified that deps.cljs doesn't work in the project?

micha13:11:17

like put atry/catch in the ns+ code

micha13:11:33

so it ignores cljs files it can't parse

jumblerg13:11:30

i did exactly that, but it failed at the time - i now realize this was because they weren't being included because once they got past hoplon ns+ got them instead.

micha13:11:07

ns+ should just ignore files it can't parse

micha13:11:36

there is also the :foreign-libs compiler option btw

jumblerg13:11:09

i had to

(->> (boot/fileset-diff @prev-fileset fileset)
                           (boot/input-files)
                           (boot/by-ext [".cljs"])
                           (reduce #(if (= (:path %2) "deps.cljs") % (conj % %2)) [])
                           (group-by boot/tmp-path))

micha13:11:25

thats probably what you have to use for js files in the project

jumblerg13:11:48

i did something like that for both hoplon and ns+ tasks, but additionally, that wouldn't work either since the deps i specified to ns+ wouldn't have been passed through to the ns macro in the resulting cljs file.

micha13:11:17

separate issue though

jumblerg13:11:39

perfect little storm

jumblerg13:11:06

on the bright side, i'm well acquainted with cljsjs now, since i assumed, at first, i was using it wrong and spent quite at bit of time going through the source.

micha13:11:11

instead of a special case for deps.cljs i would just have a try/catch

jumblerg13:11:29

yeah, might as well handle it like the error it is

micha13:11:36

because who knows what other special cases we'll need to handle

micha13:11:02

it is a model for people to emulate

jumblerg13:11:13

(and i'm referring to the cljs file with no namespace error)

micha13:11:31

so i can imagine this being a common pattern

micha13:11:39

bogus cljs files

jumblerg13:11:49

yeah, i'm sure people will invent some other new things too

jumblerg13:11:53

it would be great if we could find a way to deprecate things like this with a warning, for example, and actually move to a deps.edn file.

micha13:11:24

it's already built into the cljs compiler

micha13:11:38

nothing we can do about it i don't think

micha13:11:27

there is precedent for it in clojure unfortunately

jumblerg13:11:21

since we expose the compiler through the boot-cljs task, though, we could fix it at that interface.

micha13:11:37

the data_readers.clj file for instance

micha13:11:22

yeah but i don't think juho has any interest in that kind of change

jumblerg13:11:22

i can see how someone might not want to introduce breaking changes, but this kind of stuff only causes more pain later.

micha13:11:45

i still can't see how js code that supports cljs applications is not library code

micha13:11:38

since you have full js interop in acljs namespace

micha13:11:58

you can mix js and cljs freely

micha13:11:10

in cljs files

micha13:11:01

like you're not making js scripts that are loaded into the page via script tag

micha13:11:22

or you wouldn't need the deps.cljs file for that

micha13:11:54

if you're requiring a js namespace it seems like it's a library

jumblerg13:11:04

i can't write js in a cljs file, unless it is in a string and then passed to .eval.

micha13:11:04

and belongs in a jar anyway

micha13:11:12

(.foo js/Bar)

jumblerg13:11:15

or using the clojure syntax

micha13:11:38

right yeah

jumblerg13:11:50

but that isn't really writing javascript, that's calling javascript from clojure.

jumblerg13:11:02

in my case, i have a polyglot project.

jumblerg13:11:20

parts are actively being written by people in javascript, other parts are being written in clojurescript.

micha13:11:30

what can you do in ajs file that you can't do via interop?

jumblerg13:11:22

there are thousands of lines of javascript written already

micha13:11:35

that looks like a library to me

jumblerg13:11:42

they're being maintained by people who don't know clojurescript

jumblerg13:11:54

sure, one could argue that any namespace is a library

jumblerg13:11:18

but this adds overhead, checkout deps, additional repos, and the like. i'd argue that these are a bit more cohesive than that.

micha13:11:18

right so they make a library, since it is effectively a separate project

jumblerg13:11:02

that's what i've done, and it is ok. but it does seem that we should be able to support js files in a cljs project in as convenient as fashion as we can have .java files in a clj project.

micha13:11:10

send like a good idea to have a well defined api for the js code if those programmers are only doing the js

jumblerg13:11:16

(well, it will be ok once the ns+ bug is fixed)

micha13:11:45

and if you have a week defined api you may as well have a legit artifact

micha13:11:02

otherwise you needlessly couple the two teams

micha13:11:22

the cljs guys and the js guys

jumblerg13:11:23

but it could be for other reasons -- maybe i'm trying to optimize some of my code.

jumblerg13:11:37

so i've decided to handroll a few functions is js.

micha13:11:40

then you use intetop

micha13:11:59

cljs functions are js functions

micha13:11:36

they compile to identical code

micha13:11:37

the only use for js files is if you don't know cljs or the js already exists

jumblerg13:11:53

i think, more likely than not, i'd always use interop. maybe this hypothetical scenario where i want to hand-write some parts of my project in javascript doesn't really exist.

micha13:11:17

in both cases I'd want a separate api for the js code

micha13:11:32

because it's really a separate module

micha13:11:41

developed separately

jumblerg13:11:10

i'm merely identifying reasons i think it could make sense to have .js and .cljs files in the same project together.

jumblerg13:11:20

you could argue the same for css and html.

micha13:11:27

the js will probably want to have tests using grunt or npm or something

micha13:11:37

and so on

jumblerg13:11:17

html could be one module, css could be another module, my javascript selectors could be a third. but since the same component uses all three of them, that would be madness. they're cohesive, even through they're different languages.

micha13:11:55

straw man

jumblerg13:11:17

and i think the same applies for some js files; sure, there has to be some kind of interface, but sometimes one that is more lightweight and part of the same project is better.

micha13:11:52

if all else fails you can use :foreign-libs option

micha13:11:25

and no deps.cljs file or anything

micha13:11:53

that's what deps.cljs becomes anyway

jumblerg13:11:42

yeah, i'm grokking that... it almost seems semantically equivalent to the js task i was proposing, in fact.

micha13:11:48

iirc deps.cljs doesn't work in the cljs compiler if it's not in a jar

micha13:11:41

there is probably a jira ticket for it if that's true

jumblerg13:11:59

is it really the jar, or the config/foreign-libs config that is necessary for the compiler to make them work?

micha14:11:26

foreign libs is a compiler option

jumblerg14:11:53

which, i presume, takes some part or all of the configuration that goes into deps.cljs.

micha14:11:05

the file is a way for the jar to add to the compiler option when it's included as a dependency

micha14:11:16

the compiler needs to extract js files from the jar

micha14:11:36

that's why it probably doesn't work not in a jar

micha14:11:03

but foreign libs will work

jumblerg14:11:53

it might work out of it, the results from the previous debugging i did are useless because they also incorporated the ns+ bug.

jumblerg14:11:26

i will buy you many beers if you have the bandwidth to fix that soon, otherwise i'll try to tackle it this afternoon.

micha14:11:01

the try/catch to ignore bogus cljs files doesn't work?

micha14:11:25

i was thinking that's all we need there?

micha14:11:37

oh the second bug

micha14:11:49

i can fix that one today

micha14:11:34

the big with requiring js namespaces

jumblerg14:11:54

yeah, i'll buy the beer for that one.

micha14:11:11

OK i have to go vote for my president now

jumblerg14:11:23

flip a coin

micha14:11:28

the nation is counting on me to make the right choice

micha14:11:56

my coin has only tails

jumblerg14:11:01

yeah, you hold the fate of the world in your hands down there. up here we're contemplating more important things, like weed.

jumblerg14:11:06

nc will most likely decide the election.

micha14:11:09

good help us all

micha14:11:24

hope you like bar b que

jumblerg14:11:03

i'm laughing while i still can.

jumblerg14:11:12

(in the interim, i'll be setting up a private wagon where i can share all my extra private jars)

jumblerg14:11:20

don't get me killed

mynomoto20:11:56

@jumblerg boot-bucket looks a lot like sync-bucket task of https://github.com/confetti-clj/confetti

mynomoto20:11:59

I wonder if you knew about that project.

jumblerg21:11:16

thanks for pointing it out; i'll give it at try.

mynomoto22:11:12

I recommend it, I used on a few projects, it just works ™️ 😉

flyboarder22:11:57

does (page) actually exist anywhere or is it just magically replaced by boot-hoplon?