Clojurians
#cljs-dev
<
2017-02-15
>

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

roman01la13:02:38

Is it a known issue that compiler fails to find a namespace when using a dependency with a single source file core.clj (no *.cljs files) ? it works only with :require-macros having the same namespace in cljs also solves this

dnolen14:02:18

@roman01la what you’re saying is not very clear

dnolen14:02:41

what does “fail” to find namespace mean?

dnolen14:02:48

at a REPL?

roman01la14:02:00

I’ll post a repro later here

dnolen14:02:19

no need if this isn’t a real issue :slightly_smiling_face:

dnolen14:02:24

which is what I’m suggesting

dnolen14:02:36

ClojureScript doesn’t randomly look for .clj files

dnolen14:02:56

your assessment that you need :require-macros is correct

roman01la14:02:07

does it mean that :require-macros explicitly tells compiler to look for clj files, but with other forms of require compiler first requires cljs?

dnolen14:02:53

yes that’s how it actually works

dnolen14:02:32

however in the case that foo.cljs :require-macros foo.clj

dnolen14:02:48

when users :require foo.cljs, we will automatically bring in the macros since they have the same namespace

dnolen14:02:12

but fundamentally it’s just adding the :require-macros for you

dnolen14:02:48

in anycase what you’re describing doesn’t sound like an issue

roman01la14:02:13

that’s good to know, thanks! :slightly_smiling_face:

anmonteiro17:02:14

^ just merged

henriklundahl17:02:10

I attached a patch to http://dev.clojure.org/jira/browse/CLJS-1935, but can't set the patch field.

mfikes18:02:13

Crossing my fingers that this upstream JavaScriptCore issue might be garnering traction / interest, given the recent slew of comments https://bugs.webkit.org/show_bug.cgi?id=139847

chris-andrews18:02:10

I'm looking at the google closure compiler changelog and I see that there is an unreleased change that adds a --module_resolution flag with a NODE option that uses the node module resolution algorithm. Would this be something that would replace the need for cljs.build.api/node-inputs and its corresponding npm dependencies?

dnolen18:02:45

@chris-andrews it’s not related

chris-andrews19:02:08

the module situation is kind of confusing right now

dnolen19:02:19

Closure module resolution is just about knowing which name corresponds to what

dnolen19:02:27

it doesn’t actually figure out what inputs you need to provide

dnolen19:02:41

so we still need to do that ourselves

chris-andrews19:02:14

ok, so something along the lines of cljs.build.api/node-inputs will need to stick around to handle that

chris-andrews19:02:22

thanks for the explanation

dnolen19:02:04

for the relevant discussion

chris-andrews19:02:24

@dnolen thanks for that link, the context is really helpful

anmonteiro23:02:14

@dnolen are you familiar with cljs.pprint‘s code?

dnolen23:02:29

not especially, why?

anmonteiro23:02:16

I think that’s about the only thing preventing cljs.pprint from being loaded by bootstrap

anmonteiro23:02:36

the error we get now is form is not ISeqable at line 84 cljs/pprint.clj

anmonteiro23:02:51

I can’t figure out why it would throw that error, so I thought I’d share and ask for help :slightly_smiling_face:

dnolen23:02:54

but in bootstrap that macroexpand doesn’t work does it?

dnolen23:02:22

in regular ClojureScript macroexpand is a macro only intended for REPL usage

anmonteiro23:02:41

ah I thought macroexpand would work in that case

dnolen23:02:55

so you probably need to call into analyzer there

dnolen23:02:06

reader conditionalize to call the analyzer I mean of course

anmonteiro23:02:24

I’ll try that approach, thanks