has anyone used zxcvbn (https://github.com/dropbox/zxcvbn) with CLJS ? Does not appear to be packaged on CLJSJS ?

@superstructor Haven't used it but PRs are welcome for cljsjs. You only need externs when you use advanced compilation.

@superstructor yeah, like @kenny said, you only need externs if you’re going to do advanced compilation. another idea would be to include the zxcvbn js file on your page, and then access it with Javascript interop

has anyone used fw > 0.5.5 on node yet?

If I refer to a record in a different namespace, I seem to not to be able to use map->MyRecord directly unless I namespace it like other-namespace/map->MyRecord. Is that correct?

@jellea you can also :refer to it

i.e. :refer [map->MyRecord] explicitly

IMHO you shouldn’t really be :refering to records though

it’ll break compat if you every want to support Clojure too (e.g. via .cljc)

looks like I’m wrong there. import doesn’t seem to work with Records in CLJS

import is just for Google Closure constructors - using it to bring in JS types is not really idiomatic in CLJS

Why did clojurescript change the default optimization from simple to none?

Hello, is there any way to require lib conditionally (e.g. when js/goog.DEBUG)?

@nidu not really

but’s easy to make a namespace that you build just for dev

@dominicm because :simple is pretty slow

@nidu: if you just need it under debug and elide it otherwise, you can use goog.require

as far as I can tell :simple isn’t even a very popular setting anymore

:none and :advanced

if you need general solution also for advanced mode, look into :modules option https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules

@darwin :modules isn’t really about loading modules though, we should be clear about that

it’s only about code splitting

yeah, but that should be safe to bring dynamically on-demand

AFAIK

@darwin loading code async actually has a la carte facilities far as I know

nothing to do with :modules compiler option

but they can be paired together

in anycase, all these things muddy the waters

if you want something just for dev, make a dev namespace to load that stuff

yep, that is the safest solution I agree

(you can use :main in your build to control which namespace you get as your entry point)

@dnolen @darwin thanks for responses!

ohh, this way. I wanted to argue that this dev namespace should also be required conditionally, but i should just change an entry point. Thanks!

yep

The files that optimization none creates seems to split into "needs serving" (goog.base.js or something) and "needed for compilation" (e.g. cljc files) is there any way to separate the two with a config?

@nidu, as a side note, I prefer to use macros for conditional code, js/goog.DEBUG sounds like a good idea at first, but it needs careful treatment: https://github.com/binaryage/cljs-devtools/releases/tag/v0.5.3

to know if you are under :advanced mode, your macro could do something like this: https://github.com/binaryage/cljs-oops/blob/4e78df2b41254f3d669b86cc12cdfedad1f2ec74/src/lib/oops/config.clj#L28-L30

@darwin my case is about devtools as well but i've got compiler error that devtools.core is not found because it's only in dev dependencies.

So it's not even about dead code elimination (though that would be the next case anyway)

but better use :preloads and configure your :none and :advanced builds appropriately

no need for project code changes these days

This option actually looks pretty. I'll prefer its simplicity to build configuration. At least this time. Thanks!

Suddenly this gives another fancy error message: required "devtools.core" namespace never provided goog.require("devtools.core");

you must have it on :source-paths, and don’t use :main

in other words, ‘devtools.core’ must appear in your cljs_deps.js

so goog knows it exists and what it depends on

@nidu: Have you looked at how the devcards template works? It seems like a problem that shouldn't be happening unless there's something weird with your config.

wow, i didn't know i can omit :main. But the point here is that i don't want devtools.core to be bundled

@shaun-mahood nope, gonna take a look

@nidu devtools code will be removed by closure compiler under advanced builds via dead-code-elimination

the drawback of this approach is that you must not specify :main, which you probably want to do, to give your app an entry point and tell closure compiler which namespace is the starting point for DCE

why don’t you want to use :preloads? and configure your advanced and none builds differently

@dominicm it’s not clear to me what you are saying

@nidu: Maybe ignore me, I read devtools as devcards - repeatedly. No devtools in the devcards template. Going to step away from the computer before I screw up something important 🙂

@darwin quick search for :preloads at sample.project.clj of lein-cljsbuild didn't give results, but i guess i should search in some other places. I have different builds for dev and prod. Pretty sure the problem is incorrect config. Currently i'm poking around with approach with different entry points.

@nidu: https://github.com/binaryage/cljs-devtools/blob/master/docs/installation.md#install-it-via-preloads

@shaun-mahood no problem, fortunately there weren't a lot of files in template

and cljs-devtools-sample uses preloads to give a real example: https://github.com/binaryage/cljs-devtools-sample/blob/master/project.clj#L43

@dnolen: the cljc files created during compilation are put into a directory next to the js files that I need to serve. I need to keep them separate

@dominicm yes this is done so they are there for source mapping

there’s no way to change that, but I also don’t really see why you need to

@dnolen: the cljc files are on the classpath, which confuses tools.namespace

it’s not important for production that this happens, since you’ll generally be producing only a single JS file then

@dominicm yes nothing you can do about that

don’t put :output-dir on the classpath

@dnolen: what's the recommended way to serve in that case?

you can serve static files without polluting the classpath

there’s absolutely no reason for resources/public/js/out/ to be on the classpath

that doesn’t provide any value

@dnolen: I think it was done for uberjars. I'm not sure what the other methods to serve are though.

so it sounds like a messy config

separate the config so the uberjar stuff isn’t mixed up with everything else

this can be done with Lein’s profiles feature

you can put the :uberjar stuff only into the :uberjar profile

@dominicm: or use Boot :-)

@anmonteiro: boot has this issue too

this doesn’t have anything to do with Boot or Lein

It's not clear to me why

you often need different classpaths for different phases of development

you can manage this any number of ways

@dnolen: how would you suggest I serve in dev? That's the part I don't really get I think.

@dominicm that’s for you to sort out I have no idea what you are doing

but generally when you serve resources - you just put resources/public on the classpath

then you won’t have this problem you currently have

@dominicm What was this in relation to? Cljc files written by Cljs breaking tools.namespace?

@darwin thanks for helping with configuration, unfortunately i have to postpone solution of this subtle problem

@juhoteperi tools.namespace is red herring here

people run into all kinds of problems around the root cause

once you put the :output-dir on the classpath

it’s now Russian Roulette as to what you will get when ClojureScript tries to load something

Right, Cljs compiler has problems if the output-dir is directly part of classpath, but Cljs compiler doesn't have problem if the files are under a prefix in classpath? Do I still follow?

@juhoteperi yep

Okay, tools.namespace has a different problem. It will try to load the files even from prefix (e.g. public/js/out/foo.cljc under classpath, even if the ns is just foo)

bleh

Is this just a tools.namespace bug? I've been trying to think about configuration that would prevent this but thus far only solution has been to manually tell tools.namespace to ignore the specific dir or namespaces.

I don’t know why it needs to search the classpath like that

I guess it’s just naive

but I would consider that a bug

I'll write an issue and check if I can see an easy fix

I believe there was a conversation here a while back about how people are testing clojurescript applications, I wrote a blog post about how we're doing it on our project if anybody is interested: http://tech.adstage.io/2016/09/12/how-we-test-full-stack-clojure.html

C.t.n now does find all modified files in directories that are part of classpath, then it will read ns forms from all those files and will reload all those ns

It could easily ignore files where path is not the same as namespace

@juhoteperi: yeah, that's my underlying problem here. Figured I'd try a new angle on the solution.

@dnolen: I think I understand your recommendations now, and why they don't work for me here. Miscommunication!

Another question is that why reloading these library ns breaks the Clojure env. IIRC Sente is one of the problematic libraries.

@juhoteperi: bidi breaks, component is reported to. Its because they don't get reloaded as part of the namespace dependency hierarchy, but as a new top level, and then their protocols, or one of the other parts of the clojure global state, is blown away.

Hmm. Dependencies should be tracked per namespace name, not path

Luckily c.t.n api looks like it will be very easy to write unit tests for this

@juhoteperi: kinda. Its not expected that the libraries have changed (not sure how it distinguishes this though, possibly just something like shared folder or namespace) But then it stumbles into cljc later I suppose?