Clojurians
#cljs-dev
<
2016-06-20
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

dnolen21:06:23

@bhauman: @darwin: I’m thinking about adding a :preload compiler option

dnolen21:06:50

its just a seq of symbols that correspond to namespaces that should be loaded before the main ns

dnolen21:06:03

no dependency management or anything like that, these things should not be order dependent

bhauman21:06:19

that works for me

darwin21:06:23

sounds good to me, will definitely work for cljs-devtools

bhauman21:06:35

the before part is the best

darwin21:06:49

so library authors should provide (one) bootstrap namespace to be added to the list, right?

darwin21:06:25

e.g. in my case I would bundle devtools.boot or something similar to my library’s jar

darwin21:06:10

and users will be supposed to add it to their :preload as a configuration step for their project

dnolen21:06:38

doing this implicitly is a possibility, but I would like to wait on that to see if :preload works well enough on it’s own

dnolen21:06:08

people often setup dev stuff but they have to muck around with the classpath and requires and all that

dnolen21:06:19

now they can just dump all that stuff into some ns and :preload it

darwin21:06:33

a side question :closure-defines will be visible to those :preload code, right?

darwin21:06:06

just thinking about possible ways of passing in a configuration

dnolen21:06:14

it’s anything that needs to load right before :main

dnolen21:06:24

before this line

darwin21:06:29

btw. if you convert it to a bunch of goog.require calls, I think the dependency ordering will be solved as well, a namespace can require its dependencies and won’t require them twice

bhauman21:06:36

this is really good so people can easily separate their tooling concerns from their dependency tree

dnolen21:06:50

@darwin yes it will be a bunch of require calls

darwin21:06:50

I mean, cljs-devtools could require lib-x even if lib-x goes after it in the list, it would force to load it first, and subsequent lib-x require will be a no-op

dnolen21:06:02

we’ll also add those nses to the compilation list

dnolen21:06:24

@bhauman: exactly

dnolen21:06:43

I hit this problem today wanting to use cljs-devtools and realized we should just fix this once and for all :slightly_smiling_face:

bhauman21:06:05

the wrap pattern works but its a bit of a hoop

bhauman21:06:35

this will work for plain old closure modules as well right?

bhauman21:06:47

I see no reason why it wouldn't

darwin21:06:36

btw. is there any official naming for closure modules which pretend to be cljs namespaces? I call them in my code “pseudo” namespaces, just wondering how do you call them in cljs codebase, didn’t look for it

dnolen21:06:51

@bhauman: that’s a good point, yes it could work for those

dnolen21:06:10

@darwin I’m not aware of any conventions

dnolen21:06:31

I’ve just named and required them like any other ns

darwin21:06:04

ok, will stick with pseudo, in my case I need to distinguish between them and do things differently

darwin21:06:29

e.g. in dirac code completions I fall back to javascript completions, because I have no cljs source for them

dnolen21:06:14

^ feel free to comment on this ticket with any concerns or suggestions