Fork me on GitHub

:closure-defines {
    goog.DEBUG              false
This is being ignored in my clojurescript re-frame project. Any ideas? Doesn’t work with figwheel or a :whitespace compile


that's not the way to use the feature, in your project.clj you do this:

:closure-defines { "A value" "Another one"}
then in "":
(goog-define one "Default value one")
(goog-define two "Default value two")


@caleb.macdonaldblack Whitespace won't take closure defines. It's also noted in the docs IIRC


or use shadow-cljs where they just work 😉


has anyone used posh? ( What are your opinions?


Will Clojurescript attempt to read/use/analyse stuff in node_modules, even if you’re not using :npm-deps? I get some serious errors just trying to use package.json and node_modules for storage. I have a .js under node_modules that I added via :foreign-libs, but when compiling, it was still accessing (and erroring on) other files of that package.


In order to get it to work, I have to copy that same .js file out from node_modules, use the new location, and delete the package from node_modules and package.json entirely


@kingmob Yes, if node_modules exists, it will be used


I’m kind of surprised it’s looking at node_modules packages with npm-deps off, though


Is that documented anywhere?


:npm-deps is only about automatically installing Node modules, it is not related to being able to use libraries from node_modules


Hmm. This forces us to only use node_modules for packages that can be safely added (e.g., easily understood module formats). But there’s a zillion packages in npm, many of which aren’t nicely modularized (especially old shims we use), and this means we can’t use npm as an organizational tool.


It is possible this is not documented anywhere, the implementation was probably changed after the blogpost about npm-deps was written


I really thought npm-deps had to be on to enable this. I know cljs adds its own @cljs-oss/module-deps dependency to package.json, but I thought that was it.


There are probably four different use cases we should support: 1. Project has :npm-deps and :install-deps true 2. Project uses libraries with :npm-deps and uses :install-deps true 3. Project has package.json and packages are installed by manually running npm install and Node packages should be usable from Cljs 4. Project has Node packages installed but node_modules shouldn't be used Fourth one is currently broken. Maybe this could be fixed by adding third option (`:analyze-npm-deps` or something) which would be automatically enabled by :npm-deps or :install-deps, then only usecase 3. would need the option, and 4. would work. Or we default the option true and 4. can disable the option.


@juhoteperi or :npm-deps could optionally be false


instead of adding another option


Yes, that would work also. I'm not sure if making option take two different kinds of values (are there other options which work like this?) is much better than adding new option.


Hm, :warnings can be a boolean or map. Would make sense then.


there’s a few options that work this way and I don’t really see a problem with it


this seems like a very simple patch no?


for some reason I thought 4) was already handled, but I guess not


@juhoteperi @dnolen FWIW, my initial impression was that npm-deps meant “import these packages from node_modules for me automatically” and install-deps meant “also npm install them for me”. I assumed #4 was the case for anything not specified in either npm-deps or manually referred to in foreign-libs


@dnolen Yes, should be simple. I created issue about this (


Does the undocumented :node-modules flag ( affect any of this? Or is that just about being able to use Yarn?


@kingmob That option doesn't exists, I think that was renamed to :install-deps


As someone who has to occasionally deal with older libs/shims, I’d personally vote for not having the default be auto-processing node_modules, at least not without the ability to exclude packages from processing. E.g., just this morning I added a project that, despite using CommonJS modules, triggered a bug in Closure compiler that caused it to die. The bug is fixed in recent versions, but for now, I have to abandon using npm for the package, and copy out the .min.js


I just worry that for a long time to come, there will frequently be something interfering with wholesale processing of node_modules


Just my $.02


Hey folks I have been looking into CLJS for a very strange purpose. The OmniGroup ( is introducing automation into their apps using Javascrip for Automation (JXA). Basically a replacement for applescript. I’m trying to find out if its possible to use CLJS as a replacement/DSL for JXA.


@gganley Right off the bat, it seems like it should be possible, though there may be little issues involving config and libs


@gganley The stuff in this small repo might be useful


I think my goal is a bit different. Basically I want to write CLJS that is compiled into JS, then send it using a URL Scheme to OmniOutliner or OmniGraffle


I’ll dig into it a bit more when I have the time and hopefully be able to explain it a bit better

Garrett Hopper21:02:32

I'm writing clojurescript aws lambda (nodejs) functions. I'd like to be able to use core.async, but I can't figure out how to make my handler function not immediately return my go block before the handler's callback function has been called.


if i understand what you’re asking @ghopper, I think it’s working as expected. go blocks return a channel which the calling function has to wait on. they kind of infect your code (kind of like async/await does in javascript or any function that returns a promise).

Garrett Hopper21:02:19

Yeah, I've figured out what it's doing. I'm wondering how I can prevent the handler function from returning early before the callback has been called. Once the handler returns the channel, aws lambda kills the function with an error.

Garrett Hopper21:02:38

Do I need some sort of node await/block library?


i haven’t messed with lambda, but how would you deal with asynchronous javascript code?


often there is some sort of “done” callback with these kinds of systems

Garrett Hopper21:02:15

I'm using some node http stuff; I pass it a callback which pushes onto a channel. The problem is once that stack reaches the top handler, there's not way for me to synchronously wait for the last return.

Garrett Hopper21:02:34

I guess I could have some sort of endless loop in the handler, but that doesn't feel quite right.

Garrett Hopper21:02:55

Can I have a blocking take in javascript?


not if you want your program to ever finish


you probably want a parking take

Garrett Hopper21:02:55

But will other async stuff continue to run if I do?

Garrett Hopper21:02:07

I don't want it to finish, I just want my callback to be called.


if you block the thread that's it

Garrett Hopper21:02:31

Yeah, that's what I thought.


if you park it, other stuff can happen


so if you block a js runtime it'll be deadlocked forever

Garrett Hopper21:02:52

I can't park and wait for my function return though.


Sorry, my bad for a drive-by answer while doing >1 other things at the same time - I do think you probably want to do your handling inside that callback to stop the runtime from calling the “default” callback for you, though


I think you’re going to want a (go (let [result (<! channel-returning-function)] (callback result))


but “blocking take” is not the right name for the thing I meant


as far as I can tell aws lambda waits for you to call that callback

Garrett Hopper21:02:51

@lee.justin.m The problem is that returns a channel, which then kills the whole thing.

Garrett Hopper21:02:59

It doesn't 😕

Garrett Hopper21:02:09

It wants the callback to be called before a return.


that doesn’t make any sense. you could never do anything async if that was true (?)


note that you will for sure actually want (callback nil result) if you call callback at all, since > AWS Lambda treats any non-null value for the error parameter as a handled exception.

Garrett Hopper21:02:04

That's what I thought... I'm not sure what it's doing exactly, but I know it works if I do normal callbacks, but with a core.async channel, it doesn't.

Garrett Hopper21:02:01

@chris_johnson Thanks, I am calling it with my result as the second argument.


See, I was proposing something more like (callback nil (go (<! channel-returning-fn))) but reading it now, I’m pretty sure that will just return the JSON.stringifyd representation of the channel


which is likely Not Helpful

Garrett Hopper21:02:56

Yeah, I've been trying (go (callback nil (<! channel-returning-fn))).

Garrett Hopper21:02:34

How would I create an endless loop that allows async stuff to continue running?

Garrett Hopper21:02:15

That just returns a channel immediately, no?

Garrett Hopper21:02:05

Huh, I might be an idiot...

(defn ^:export handler [event context callback]
  (when callback
    (go (callback nil (clj->js {:statusCode 200
                                :headers {}
                                :body (<! (go
                                            (<! (timeout 1000))
                                            "body")) })))))
Seems to work

Ryan Radomski21:02:10

Inside of the go loop you can continuously pull off of a channel endlessly. The channel that it returns allows you to manage that lifecycle

Garrett Hopper21:02:38

Nevermind, I don't think what I thought was happening is happening.


you aren’t waiting


I think the problem is that the go block doesn’t traverse function boundaries. so it doesn’t traverse clj->js

Garrett Hopper22:02:46

Anecdotally the function definitely seems to wait the specified amount of time, and it returns the correct body.


does this work

(defn ^:export handler [event context callback]
  (when callback
    (go (let [result (go (<! (timeout 1000)))]
          (callback nil (clj->js {:statusCode 200
                                  :headers {}
                                  :body "body"}))))))


sorry but...what were you trying? I don't seem to get it...


can't you just

(defn ^:export handler [event context callback]
  (when callback
      (<! (timeout 1000))
      (callback nil (clj->js {:statusCode 200
                              :headers {}
                              :body "body"})))))


right i think it need to be like that because the way you had it before, the outer go block cannot “see” past the clj->js function invocation so it doesn’t park and returns immediately

Garrett Hopper22:02:01

@lee.justin.m I'm trying yours now. It seems to park and wait even within clj->js. The function waits the 5 seconds I told it to wait, and it returns the correct body. (not some json channel representation)

Garrett Hopper22:02:06

Huh, your let/result function works exactly the same. I didn't think it would, since the result wasn't being used. I guess I don't entirely understand what the go macro does.


what does callback look like?


callback is part of the aws api


and does it return a value? a channel? or other thing?

Garrett Hopper22:02:16

@joelsanchez I suppose yours would work as expected to. Another case of me not understanding how go works.

Garrett Hopper22:02:29

Yeah, I don't have access to callback.


ok but what does it return? did you try (type (callback nil ...)) to know?

Garrett Hopper22:02:01

Once callback is called, the function is killed.


i’m pretty sure that this is what’s going on: aws waits for the javascript even loop to drain before killing your function and calling the default callback handler


if you don’t set up your go blocks correctly, they won’t park, and they’ll finish immediately

Garrett Hopper22:02:08

Huh, that'd make sense. I believe the issue was that I had a go block wrapping the whole http request function, but I was using parking-gets inside node api callbacks.


if the caller of handler does not <! its result, there's no way to block: handler will always return immediately


but that’s not a problem because that’s how aws works anyway: it waits for the event loop to drain


the problem is that if you don’t have the go blocks set up, it will just finish and not have anything waiting

Garrett Hopper22:02:37

@joelsanchez Yeah, the issue isn't actually handler returning immediately as I thought. I like @lee.justin.m's theory of the event stack draining.


“When the callback is called, the Lambda function exits only after the Node.js event loop is empty (the Node.js event loop is not the same as the event that was passed as a parameter).”

Garrett Hopper22:02:27

Where'd you find that?


^ I assume it waits for the event loop to drain even when you don’t call the callback handler


@ghopper for what it is worth, I don’t know what go blocks are doing either. state machine something something 🙂