Fork me on GitHub
#clojurescript
<
2016-09-13
>
superstructor01:09:34

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

kenny01:09:59

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

chrisetheridge10:09:09

@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

pat14:09:10

has anyone used fw > 0.5.5 on node yet?

jellea15:09:46

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?

anmonteiro15:09:50

@jellea you can also :refer to it

anmonteiro15:09:26

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

anmonteiro15:09:12

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

anmonteiro15:09:33

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

anmonteiro15:09:09

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

dnolen15:09:50

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

dominicm17:09:04

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

nidu18:09:32

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

dnolen18:09:50

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

dnolen18:09:24

@dominicm because :simple is pretty slow

darwin18:09:59

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

dnolen18:09:00

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

dnolen18:09:08

:none and :advanced

darwin18:09:32

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

dnolen18:09:06

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

dnolen18:09:13

it’s only about code splitting

darwin18:09:29

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

dnolen18:09:52

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

dnolen18:09:58

nothing to do with :modules compiler option

dnolen18:09:06

but they can be paired together

dnolen18:09:27

in anycase, all these things muddy the waters

dnolen18:09:37

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

darwin18:09:36

yep, that is the safest solution I agree

dnolen18:09:46

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

nidu18:09:56

@dnolen @darwin thanks for responses!

nidu18:09:40

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!

dominicm18:09:00

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?

darwin18:09:03

@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

nidu18:09:02

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

nidu18:09:28

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

darwin18:09:35

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

darwin18:09:52

no need for project code changes these days

nidu18:09:12

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

nidu19:09:14

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

darwin19:09:20

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

darwin19:09:30

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

darwin19:09:47

so goog knows it exists and what it depends on

shaun-mahood19:09:29

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

nidu19:09:50

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

nidu19:09:03

@shaun-mahood nope, gonna take a look

darwin19:09:23

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

darwin19:09:34

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

darwin19:09:11

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

dnolen19:09:38

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

shaun-mahood19:09:28

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

nidu19:09:14

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

nidu19:09:19

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

darwin19:09:16

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

dominicm19:09:25

@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

dnolen19:09:52

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

dnolen19:09:07

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

dominicm19:09:34

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

dnolen19:09:35

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

dnolen19:09:05

@dominicm yes nothing you can do about that

dnolen19:09:12

don’t put :output-dir on the classpath

dominicm19:09:54

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

dnolen19:09:09

you can serve static files without polluting the classpath

dnolen19:09:05

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

dnolen19:09:15

that doesn’t provide any value

dominicm19:09:29

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

dnolen19:09:54

so it sounds like a messy config

dnolen19:09:11

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

dnolen19:09:13

this can be done with Lein’s profiles feature

dnolen19:09:23

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

dominicm19:09:39

@anmonteiro: boot has this issue too

dnolen19:09:58

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

anmonteiro19:09:06

It's not clear to me why

dnolen19:09:08

you often need different classpaths for different phases of development

dnolen19:09:17

you can manage this any number of ways

dominicm19:09:31

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

dnolen19:09:49

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

dnolen19:09:07

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

dnolen19:09:18

then you won’t have this problem you currently have

juhoteperi19:09:02

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

nidu19:09:10

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

dnolen19:09:40

@juhoteperi tools.namespace is red herring here

dnolen19:09:50

people run into all kinds of problems around the root cause

dnolen19:09:11

once you put the :output-dir on the classpath

dnolen19:09:27

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

juhoteperi19:09:24

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?

juhoteperi19:09:11

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)

juhoteperi19:09:44

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.

dnolen19:09:07

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

dnolen19:09:21

I guess it’s just naive

dnolen19:09:33

but I would consider that a bug

juhoteperi19:09:46

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

therabidbanana19:09:51

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

juhoteperi19:09:42

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

juhoteperi20:09:00

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

dominicm20:09:37

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

dominicm20:09:21

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

juhoteperi20:09:41

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

dominicm20:09:09

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

juhoteperi20:09:54

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

juhoteperi20:09:19

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

dominicm20:09:08

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