Fork me on GitHub
#clojurescript
<
2022-02-25
>
manas_marthi14:02:15

Hi @dnolen I am just checking Clojurescript open issues. There are close to 2000 issues. I hope a lot of aging tickets are corner cases/low priority items. Was it assessed how many of them are critical and production breaking ? Can I bet my next billion dollar super duper awesome app or website on Clojurescript? Does Cognitect provide commercial support?

Alex Miller (Clojure team)14:02:14

Any large open source project has a lot of open old bugs, that's just software. There are several billion dollar companies built on Clojure and ClojureScript so I think the answer is yes there. Cognitect does not currently provide commercial support contracts. We used to, and we sold a few, but no one ever found anything that they needed us to fix.

6
1
👌 1
😁 1
mkvlr15:02:42

True for any large open source project, except elixir which currently has https://github.com/elixir-lang/elixir/issues. Always amazed how they manage to keep it that low.

Alex Miller (Clojure team)14:02:45

By the nature of Clojure and ClojureScript, being Lisps, the scope of things you can fix yourself if absolutely needed is large

Alex Miller (Clojure team)14:02:04

My guess is that if you had an urgent bug, you'd probably find far better free support here on this Slack than you'd get from most commercial support contracts

metal 1
💯 1
manutter5114:02:35

Our company is currently deploying two largish, mission-critical apps that depend on Clojure and ClojureScript, and I'd say it's not merely reliable, it's a huge advantage to us.

1
👍 2
1
manas_marthi14:02:25

Hi Alex, that was a very quick response. Thank you very much.

dnolen15:02:34

@manas.marthi I think the user base is large enough (and it used for serious work) so truly critical bugs are usually communicated and addressed in a reasonable amount of time.

1
1
dnolen16:02:49

also probably just need to do some gardening of some old stuff 😛

Lone Ranger16:02:10

I've got a figwheel cljs project that's big enough that hot reloading is failing because the bootstrapping/initialization sequence is still running before all the dependent files reload. Yes, yes, I know that it should just be engineered better, but does anyone have a band-aid?

1
manas_marthi14:03:16

Slowing reloads down Depending on your environment Figwheel may reload files too quickly. If it does reload too soon it may be reloading the old file before it has changed. This is not an ideal experience. For example you may be working with a Jekyll site where Jekyll copies all the assets of the site to a _site directory and serves the site from there. Jekyll currently doesn’t copy the files fast enough to beat Figwheel’s reload time. You can slow down this reload time with the :wait-time-ms option. It defaults to 50 milliseconds. You can make each reload wait a second after each compile by setting :wait-time-ms to 1000.

manas_marthi14:03:27

Found this on the documentation

Lone Ranger16:02:59

For now I've disabled hot reload but that's such a bummer

borkdude16:02:08

Play online with CLJS and Reagent in CodePen via #scittle :) https://codepen.io/Prestance/pen/PoOdZQw Thanks @admin055

dnolen17:02:16

@goomba I think Figwheel has a hook so you can wait for reload, you can probably conditionalize it

Lone Ranger17:02:02

Yeah, I was using the ^:after-load hook but it doesn't seem to actually wait until ALL dependent files are reloaded. Not sure how to conventionalize on all dependencies reloaded, although I suppose (a/<! (a/timeout 2500)) or something would be a hack worth trying

awb9917:02:16

Can someone tell me how "format" works on clojurescript? I would like to format numbers and dates.

awb9917:02:46

I found goog clojure libraries to format numbers, and tick.core library to format dates.

awb9917:02:35

What I did not find is an interface where I can register tick.core to format dates and goog clojure to format numbers.

awb9917:02:58

I guess this must be commonly needed feature.

wevrem03:02:57

When you say you want to “register” one of those libraries to format dates and numbers, where exactly are you needing formatted values to go? Are you formatting them for display on a webpage? to the console? the REPL? storing them in a database? is this for “over the wire” data as part of JSON or transit?

Alex Miller (Clojure team)17:02:58

it's Friday and if you're looking to slack off for a few minutes, why not answer the 2022 Clojure survey? takes 5-10 min. https://www.surveymonkey.com/r/clojure2022

3
neilyio19:02:01

Wondering if anyone has seen this error before in the browser from their compiled CLJS: Uncaught SyntaxError: Invalid left-hand side in assignment. It’s happening at this line in my output file, bundle.js:

38472       "development" = goog.define("process.env.NODE_ENV", "development");
… which, of course, is invalid. It seems to be happening while I run my :bundle-cmd. Here’s my full compilation call:
(cljs.build.api/build
   {:output-dir    "public/cljs",
    :output-to     "public/cljs/prebundle.js",
    :asset-path    "cljs",
    :main          "cljs.user",
    :install-deps  true,
    :optimizations :whitespace,
    :target        :bundle
    :bundle-cmd    {:default ["esbuild" "public/cljs/prebundle.js"
                              "--bundle" "--outfile=public/cljs/bundle.js"]}
    :npm-deps      {"react"             "17.0.2",
                    "react-dom"         "17.0.2",
                    "@react-spring/web" "9.4.2"}})
As you can see, I’m running esbuild on prebundle.js to produce bundle.js. The weird thing is that if I look at the same line in prebundle.js, then I see this:
process.env.NODE_ENV=goog.define("process.env.NODE_ENV","development")
Seems like my :bundle-cmd is replacing process.env.NODE_ENV with the literal string "development", and then trying to assign to it. I realize this could be esbuild messing up… but I wanted to ask if anyone’s run into this before.

neilyio19:02:04

Upon further experimentation, I’m realizing this only happens with :optimizations :whitespace. The other optimization levels work properly. Does anyone have any insight into why this happens?

neilyio20:02:48

Resulted in a new error, though. This time from the Clojure process that’s doing the compilation.

Feb 25, 2022 12:01:42 PM com.google.javascript.jscomp.LoggerErrorManager println
WARNING: public/cljs/inferred_externs.js:15:0: WARNING - [JSC_UNDEFINED_EXTERN_VAR_ERROR] name goog is not defined in the externs.
  15| goog.dependencies_;

thheller20:02:07

this is standard practice in JS to replace NODE_ENV. you are never expected to assign it in your program.

thheller20:02:46

also don't use :whitespace ever. at the very least you need :simple better even :advanced

mikerod17:06:47

I know this is old, but I got the same thing with :whitespace optimizations in recent 2023 stack using webpack as the bundler. It seems to me that goog closure is misinterpreting what process.env.NODE_ENV is to be a goog.define or something…

mikerod17:06:18

I find it odd that we just cannot use :whitespace. I wanted to just for a debug friendly build when trying to run a JS test runner.

thheller17:06:53

yes, do not use :whitespace. I have no clue why you think you need it. it should not exist, it only exists for historic reasons. :whitespace is pointless, just don't use it.

thheller17:06:13

if you want a debug friendly builds, use the dev builds 😛

mikerod17:06:39

It is more readable if you pretty print it

mikerod17:06:23

Well, I was using jsdom for a bit and it couldn’t deal with :none optimizations at all. Doesn’t like document.write("<script>..."); This was no using shadow - which I think may go a different route

mikerod17:06:40

But either way, if you use :simple there is a bunch of name munging. If using a devtools step debugger on that, it’s less than ideal.

mikerod17:06:55

In the repl things are fine. The problem is CI headless browser tests.

thheller17:06:02

no source maps?

mikerod17:06:10

The problem space is when tests are fine in repl, but not in the CI headless env.

thheller17:06:11

:simple should come with source maps

mikerod17:06:24

Should the source maps work for devtools step debugging?

mikerod17:06:32

Perhaps I haven’t configured this correctly then.

mikerod17:06:13

I’m also just really curious for no other reason than curiosity of how:

"development" = goog.define("process.env.NODE_ENV", "development");
ends up happening

thheller17:06:27

can't speak to any none shadow setups. no clue what they do

mikerod17:06:31

I see it happens with webpack and esbuild. It seems it isn’t responsible for it. I guess the cljs compiler is? But I don’t see how.

thheller17:06:49

no clue, not enough context to answer

mikerod17:06:17

I’m only doing mode=dev for webpack, so nothing else ever even mentions process.env.NODE_ENV directly, very strange. Also, weird that only whitespace has this issue. Nothing else.

thheller17:06:38

webpack tends to just replace process.env.NODE_ENV with whatever value it is supposed to have

mikerod17:06:43

My context is about the same as what was said above - except I bundled with webpack

thheller17:06:53

so if the code had process.env.NODE_ENV = goog.define... thats a problem

mikerod17:06:01

Yeah, That’s what happens above too, and yes the code comes out just like that

mikerod17:06:16

process.env.NODE_ENV = goog.define... but I don’t understand what step in the tooling could be pulling this off

thheller17:06:18

did you identify where the code is from?

thheller17:06:38

look at the code before webpack or any JS tools gets involved

mikerod17:06:44

since it says goog.define - I assume cljs compiler + closure right? I don’t do anything beyond that

thheller17:06:47

then look at cljs sources

mikerod17:06:53

It happens in a very minimal project - with nothing going on

thheller17:06:16

I mean it is coming from this, just not sure what this is used for

thheller17:06:29

(shadow doesn't have anything like this)

mikerod17:06:59

Yep you found that fast! that is it. I just found the compiled files myself

mikerod17:06:15

process/env.js - and indeed comes from cljs

mikerod17:06:50

I don’t understand why cljs is doing that. I guess it only breaks whitespace because in simple/advanced it is somehow dead-code eliminated or something? super weird

mikerod17:06:16

and I’m curious still why :none doesn’t have a similar issue

thheller17:06:28

in :simple the goog.define is just inlined with whatever value it is supposed to have

thheller17:06:45

so you end up with process.env.NODE_ENV="development"

thheller17:06:14

a simple workarround is replacing that file on your classpath

thheller17:06:23

just an empty ns should work

mikerod17:06:34

Yeah, that makes sense

mikerod17:06:53

I was wondering if I could just opt out of it with opts, I’ll look

thheller17:06:21

:process-shim false it seems?

mikerod17:06:35

Yeah, I found that too. I’m not sure what that’ll do otherwise haha

mikerod17:06:50

Also that commit there explains why :none is ok - it is skipped when :none

mikerod17:06:13

Sorry to bother you with it. I realize you already don’t do this with shadow

mikerod17:06:02

So I guess this is a feature for if you are trying to use node modules directly within the cljs compilation - rather than handling them independently via a separate bundler

mikerod17:06:17

Hah, in a funny twist of fate. Setting :process-shim false did help me remove this. Then I started to get errors with goog.dom being undefined, which points me more at https://clojurians.slack.com/archives/C03S1L9DN/p1656184727433179?thread_ts=1656183740.910699&amp;cid=C03S1L9DN Which is an issue I just checked earlier and linked to this issue. So basically, I came full circle.

thheller17:06:23

hmm yeah ticket doesn't explain much why this exists

mikerod17:06:19

Yeah, I think I understand this implicit preload for when you try to bring node modules directly through the closure compiler? but I’d think it’d always be a problem in a bundler with that sort of JS produced.

mikerod17:06:45

But yeah, I think I don’t need it. Funny how I then got to goog.dom broken. I think I’ve had goog.dom issues before.

thheller17:06:09

goog.dom just cannot be loaded in node since its tries to access the DOM I think

mikerod17:06:22

Perhaps the takeaway is just that :whitespace is pretty unreliable/broken in pure cljs 😆

thheller17:06:51

or use shadow and don't worry about any of that 😉

mikerod17:06:54

I just had a cljs :require on goog.dom here. Nothing with node other than using it as the bundler later.

mikerod17:06:07

Yeah, considering shadow, but a bit of a haul to uplift our org to from fig

mikerod17:06:25

Also, jdk 11 min compliicates our CI pipeline. We have to use jdk8 for our bytecode stuff.

thheller17:06:35

don't have to use it for everything. just this one use case could be a start

mikerod17:06:40

Not the end of the world, just requires work. I’m trying to way the pros/cons of shadow-cljs

mikerod17:06:55

The stuff I mostly work on is our “common” infrastructure.

mikerod17:06:01

And this case is part of it. So it’d be pervasive

thheller17:06:09

don't know what you mean by bytecode stuff

mikerod17:06:16

We compile uberjars for web apps

mikerod17:06:30

They have a webserver for the JVM - so we use clj

mikerod17:06:39

We compile clj & cljs in the same pipeline

mikerod17:06:45

the js compiled goes into the jar file

thheller17:06:03

and the production setup runs jdk8?

mikerod17:06:30

So basically, I’d have to have steps like:

use jdk8
somebuildtool compile-clj
use jdk11
somebuildtool compile-cljs
use jdk8
... the rest...

thheller17:06:31

you can target any specific java version, so even jdk19 can produce bytecode for jdk8

mikerod17:06:51

I don’t know how much I trust compiler opt flags on jvm

mikerod17:06:03

Not in business critical delivers haha

mikerod17:06:13

eg. telling jdk11 to compile 8 bytecode

thheller17:06:17

well they have existed for decades at this point and always work

mikerod17:06:33

They have deficiencies though. They don’t catch using new jre classes

mikerod17:06:49

so you can end up bundling in callsites to jre classes that wont’ exist at link time

mikerod17:06:19

uberjar doesn’t bundle in the standard JRE java modules/libs

mikerod17:06:51

I realize we’ve very much digressed from cljs though!

mikerod17:06:21

I very much appreciate the feedback though.

thheller17:06:23

yeah sorry I'm out. sounds like a self imposed problem. and just a warning CLJS will be moving to java11 too, it has to or left behind a years old closure compiler version.

thheller17:06:39

so at one point you'll have to deal with it or stay with the old version forever.

mikerod17:06:41

Yeah, I recognize cljs is going to have to go jdk11 soon when taking on newer closure

mikerod17:06:10

You are lucky if you aren’t involved in a prod delivery mode with the jvm though. Java 8 is going to be a burden to deal with for probably at least 5 more years

thheller17:06:39

I have left jdk8 behind a long time ago, in every setup. don't know why you'd stick with something that old today anways 😛

mikerod17:06:46

It was the last version of the old release cadence era. It got special cased by a bunch of enterprise’y contracts and LTS support lines.

mikerod18:06:18

Try delivering jars to clients in areas of the financial space

mikerod18:06:24

Or even healthcare

mikerod18:06:35

If you are able to cloud host your own stuff or something like that - much more ideal

thheller18:06:38

luckily I don't do that 😉

thheller18:06:04

but I guess none of that really matters to what you do in development?

mikerod18:06:30

Doesn’t matter too much. We’d prefer our tests in clj to run against jdk8 just to check what we deliver, but that’s it

thheller18:06:40

I mean just use the -source and -target options and some discipline to not use that doesn't exist in jdk8

mikerod18:06:00

Yeah, that can work. It’s just when you use open source libs - you have to be careful they do not use what doesn’t exist.

thheller18:06:00

but yeah. you know how to solve it 😉

mikerod18:06:46

Thanks though. This has been illuminating. And at least now I know why there was this “invalid left-hand side in assignment”

mikerod01:06:17

https://clojurians.slack.com/archives/C1AC4BU2K/p1686319130660819 See type hint issues with using higher jdk to compile lower javac. Just as another reason to worry a bit about doing it that way. ☠️

Stephen20:02:32

Hello firends, I am trying to integrate clojurescript in my frontend, my backend being python and using node/socketio for websockets. What library would you recommend to talk over websockets with socketio from my clojurescript? Sente seems to expect my backend to also run Sente, or does it? Thank you 🙂

p-himik21:02:39

> Sente seems to expect my backend to also run Sente That's correct. There are probably JS clients for socketio that you can use from CLJS via interop. And if not, you can always just use a raw WebSocket connection, without any libraries.

Stephen22:02:28

okay, thank you, I will try

Stephen22:02:13

Wow, perfect, I will check that also, as soon as I have my other problem fixed 😉 Thank you @U0JUR9FPH. Maybe you guts can help me also with the other thing I posted in the mainchannel :))

Stephen22:02:22

I am really struggeling to get Calva to connect to my app.... I am serving my javascript code from another webserver.... I have this in my shadow-cljs.edn

{:app {:target :browser
        :output-dir "../public/js"
        :asset-path "/js"
        :modules {:main {:entries []}}}}
The shadow-cljs watch app is working and when I navigate to the file where I server the main.js everything seems to work fine. When I save my source.cljs file, the code gets "hot-reloaded". But when I Calva jack in to my :app and select browser repl, it wants me to connect to localhost:9630 for the js execution environment. When I do, it also works, but when I insert
(js/alert "hello world")
the alert will then appear in that localhost:9630 tab and not, where my app is running. Any Ideas?

p-himik22:02:39

That sounds like a question for #calva

🙌 1
Stephen22:02:44

ok, thank you, I will repost it there 🙂

👍 1
jaide23:02:56

Can you paste your whole config please?