:closure-defines {
    goog.DEBUG              false
    goog.WP_SERVER_URI "I PROMISE I WORK"}

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

:closure-defines {
  my.app/one "A value"
  my.app/two "Another one"}

(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? (https://github.com/mpdairy/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.

Thanks @juhoteperi!

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?

4) I mean

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 (https://dev.clojure.org/jira/browse/CLJS-2494).

Does the undocumented :node-modules flag (https://dev.clojure.org/jira/browse/CLJS-2245) 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

Ahh, ok.

The change was reverted: https://github.com/clojure/clojurescript/commit/aa5b09b09989be5e529c3be172e35eb1aa8c98c5#diff-84ffd22349e5ca1fe6322cb0e379b3b1

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 (http://omnigroup.com) 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. https://omni-automation.com

@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 https://github.com/blackgate/cljs-jxa-starter

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

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).

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.

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

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.

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

https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html#nodejs-prog-model-handler-callback <-- I think you want to be doing a blocking take on your channel inside your callback

Can I have a blocking take in javascript?

not if you want your program to ever finish

you probably want a parking take

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

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

if you block the thread that's it

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

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

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

It doesn't 😕

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.

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.

@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

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

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

go-loop

That just returns a channel immediately, no?

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")) })))))

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

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

you aren’t waiting

These examples might help you out https://clojuredocs.org/clojure.core.async/go-loop

@lee.justin.m What do you mean?

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

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
    (go
      (<! (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

@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)

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?

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

Yeah, I don't have access to callback.

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

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

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

right

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

@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).”

Where'd you find that?

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

search for “event loop” https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html

Cool, thanks

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

@lee.justin.m Haha, thanks