Fork me on GitHub
#clojurescript
<
2017-12-21
>
bja07:12:06

So this might be a little crazy, but is there a way to do node module loading from a node_modules directory for a nashorn interpreter? i.e. if I ran npm install with a package.json to get all of the dependencies, there would be some shim that I could load and pass it the node_modules File object

bja07:12:02

I want to run some code that doesn't do a ton of IO, so I suspect that it'll work on nashorn without too much effort, but for various reasons I'm not thrilled out shelling out to a node process to get what I want

bja07:12:22

actually, this looks like exactly what I want: https://github.com/coveo/nashorn-commonjs-modules

guliy09:12:05

Could someone help me understands it’s only my problem or they are common. in short, I have a small project on cljs under the nodejs with cider + figwheel. After build js bundle and the application starts, the REPL becoms very slow. Just evaluating single-line may takes up to 10 seconds, and the REPL periods simply die. sometimes i get a message - Figwheel: message from client couldn’t be read! clj and cljs versions 1.9 and 1.9.946.

qqq10:12:52

I'm not a cljs expert; but it seems like this is hard for others to debug unless you ca npost a repo with your complete config

tomc14:12:48

@seako Thanks for the info!

arnout17:12:03

Using cljs.test/run-all-tests, how do I access the summary/result? The macro run-tests-block cleans the *current-env* before I have a chance to access it. How do other people do this?

thheller17:12:55

(let [env (test/empty-env)] (test/run-all-tests #".*" env) (inspect-env env))

thheller17:12:49

I think that lets you access the result in env

arnout18:12:13

I tried, does not seem to work.

arnout18:12:50

For now I found a very hacky way:

(def summary (volatile! nil))

(defmethod test/report [::test/default :summary] [m]
  (vreset! summary m)
  (println "\nRan" (:test m) "tests containing"
           (+ (:pass m) (:fail m) (:error m)) "assertions.")
  (println (:fail m) "failures," (:error m) "errors."))

plins18:12:25

hello everyone, using cljs (reframe) how do I register a handler to the beforeunload event?

manutter5118:12:10

Hi @plins there’s a #re-frame channel you may be interested in. I think the answer to your question is that reagent/re-frame often does not need as many of the React lifecycle events, due to the way the re-frame subscription model works.

manutter5118:12:20

What do you need beforeunload for?

plins18:12:17

I would like to clean parts of my application state (`db` in re-frame) when an user leaves the page (hits the back button, or, whatever)

manutter5118:12:24

Ok, I’d suggest posting that question in the #re-frame channel, you’ll probably get better answers than I could give you

dehli20:12:07

Has anyone here been able to bundle a package containing :npm-deps?

thheller20:12:34

as in write a library that declares :npm-deps or use :npm-deps in your project?

dehli20:12:47

the first option

dehli20:12:26

I have the 2nd option working, and now i’m trying to publish the package, but the npm deps aren’t being included (just doing a local install for now)

thheller20:12:13

the project user has to specify :install-deps true so the :npm-deps are installed properly. did you try that?

dehli20:12:54

i have that in the “library”

juhoteperi20:12:06

And does the library define :npm-deps in deps.cljs, not compiler options or such?

dehli20:12:07

would all consumers of it also need to specify it?

dehli20:12:42

gotcha. and it has it defined in compiler options. will it need to be done in deps.cljs instead?

juhoteperi20:12:19

Yes, Cljs compiler is not able to read project.clj of libraries

dehli20:12:57

thanks! that gives me some more things to try 🙂

juhoteperi20:12:39

I think this hasn't been documented anywhere. And personally I'm not fan of letting Cljs libraries to install npm packages, but at least it doesn't do anything with :install-deps

dehli20:12:11

I wonder if I could just publish the bundled package so install-deps would only need to be run from the library

juhoteperi20:12:41

Bundled package? The processed JS modules and then using those as Closure libs? Might be possible, but would be quite a hack. And one benefit on npm-deps is that user can update those without repackaging things to Clojars or such.

juhoteperi20:12:48

Currently my favorite solution is for a library to default to Cljsjs foreign-libs but also support npm-deps if user decides to use those in application. This is how Reagent 0.8 will work.

dehli20:12:45

Ya, that’s what I was referring to. With that solution, would the user need to manually add the dependent libraries?

juhoteperi20:12:31

If processed JS modules were packaged, no. But the output would depend on Closure-compiler version, and it is possible the processed JS wouldn't work with other Closure versions.

dehli20:12:22

cool. I will have to investigate that as well b/c the idea of being able to update the libraries independently of a new library release is appealing.

dehli20:12:50

quick question, when you said And one benefit on npm-deps is that user can update those without repackaging things to Clojars or such. user here refers to a library consumer, right?

juhoteperi20:12:20

:npm-deps in application compiler-options will overwrite deps from libraries, so updating those will be easy compared to packaging processed JS

dehli20:12:11

thanks! i guess one downside would be that there’s no guarantee your library would work with the specified version but I definitely see its appeal

joelsanchez20:12:38

just noticed I have this PR pending since march https://github.com/kawasima/fressian-cljs/pull/7 does no one maintain fressian-cljs? 😮

dehli21:12:04

So should my deps.cljs look like:

{:npm-deps {:library "version"}}
or should i follow the :foreign-libs syntax? Edit: Looks like this is the right way to do it b/c I’m now getting the packages installing. Still having issues, but one step closer