Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-12-01

Channels

#shadow-cljs
<
2022-12-01
>
seepel00:12:33

I have a shadow-cljs project and I’d like to write a large portion of it using Typescript/React. What is a good way to setup my project?

thheller07:12:30

and then use whatever else for typescript, as shadow-cljs doesn't support that at all

gratitude-thank-you 1
niwinz08:12:31

hello @thheller I found a strange case that is happening in a while on our project. We have the following release config: 

:compiler-options
   {:output-feature-set :es2020
    :output-wrapper false
    :warnings {:fn-deprecated false}}

   :release
   {:closure-defines {goog.DEBUG false
                      goog.debug.LOGGING_ENABLED true}
    :compiler-options
    {:fn-invoke-direct true
     :optimizations #shadow/env ["PENPOT_BUILD_OPTIMIZATIONS" :as :keyword :default :advanced]
     :source-map true
     :elide-asserts true
     :anon-fn-naming-policy :off
     :source-map-detail-level :all}}}
but the *assert* is still true (we have released some "in development" code (new features) to production build because of this hehehe)

niwinz08:12:52

do you have any hints why this can happen?

thheller08:12:17

what is *assert*?

niwinz08:12:46

assert is a dynamic variable set on compile time, by the :elide-asserts true

thheller08:12:57

yes, but when are you "testing" it?

niwinz08:12:11

on release build

thheller08:12:13

it is a runtime binding, so it is only bound to false while compiling?

thheller08:12:52

it already defaults to eliding asserts in release builds, dunno why you are setting it?

niwinz08:12:07

just for explicitnes

thheller08:12:43

I still don't know what problem you are describing though

thheller08:12:56

how or where does this problem manifest?

thheller08:12:16

assserts are removed in release builds, so what does *assert* mean to you?

niwinz08:12:52

I expect *assert* value to be false on production builds, and I think it worked in this manner for some time

niwinz08:12:03

we have our own assets macro helpers, and also we used this for exclude code from production builds, and it worked when we started to using it, but now is no longer working (and I don't know really when it happened)

thheller08:12:22

again I ask: WHEN should it be false? in what context? when and where are you looking at it?

thheller08:12:41

it is bound to false, via binding. so it really really depends on when and where you are looking at it

niwinz08:12:09

this is one use case, it worked in the past, right now, is obviously does not work, because the *assert* has value true on release builds

thheller08:12:22

that is CLJS code

thheller08:12:31

*assert* is a CLJ runtime binding, so it only works in macros

niwinz08:12:42

yep, ok, I understand it, I just asked for a hint, because in the past is also worked outside macros because the value of this var was set to false on release builds, thats it

thheller08:12:27

that might be true for regular cljs maybe? I have never modified how this worked in shadow-cljs

thheller08:12:40

maybe you tested with the self-hosted compiled?

niwinz08:12:50

in any case, thanks for your time, I expect this value to be true right now independentry of :elide-asserts on cljs code

thheller08:12:53

I can find any reference on this ever getting bound during normal cljs compilation

thheller08:12:28

yes, it is always true

thheller08:12:16

you could just change the (when *assert* to (when ^boolean js/goog.DEBUG

thheller08:12:32

to achieve the same but get rid of the *assert* assumption

thheller08:12:43

you could also introduce your own goog-define

niwinz08:12:59

yep, is what I going to do, We clearly used incorrectly the *assert*, It just worried me a bit because when we writted this code and other similar one, because it worked on first time, but I don't know why. In any case it is not shadow fault

niwinz08:12:56

in any case, thanks for your time

kokonut22:12:11

I am using shadow-cljs and once I included cljs-http I am getting this message about dependency conflict. Is there any way to resolve them? I used to handle this type of conflict in lein on backend but I am still a newbie on frontend (shadow). 

[:frontend] Build completed. (232 files, 133 compiled, 2 warnings, 0.84s)

------ WARNING #1 - :redef -----------------------------------------------------
 Resource: no/en/core.cljc:131:1
 parse-long already refers to: cljs.core/parse-long being replaced by: no.en.core/parse-long
--------------------------------------------------------------------------------

------ WARNING #2 - :redef -----------------------------------------------------
 Resource: no/en/core.cljc:136:1
 parse-double already refers to: cljs.core/parse-double being replaced by: no.en.core/parse-double
--------------------------------------------------------------------------------

kokonut22:12:47

It seems the same topic was already discussed. https://clojurians.slack.com/archives/C6N245JGG/p1657707256386529 But it also looks like there is no way to resolve or oppress the warning.

kokonut22:12:36

My case is worse because when I see this message my cljs repl on cider doesn't work properly. I may have to avoid using cljs-http and use cljs-ajax instead.

dpsutton23:12:58

why doesn’t your repl work properly?

dpsutton23:12:55

the solution is to have the dep that defines parse-long and parse-double to exclude those with (:refer-clojure :exclude [parse-long parse-double])

kokonut23:12:56

I honestly don't know. Once I included this lib in shadow-cljs, I get this error. 

No available JS runtime.
See

dpsutton23:12:19

and that error goes away if you exclude the cljs-http dep?

kokonut23:12:27

yes, exactly.

dpsutton23:12:43

raise an issue with CIDER. that is bizarre and unexpected

dpsutton23:12:05

if you can get a minimal repro that would be handy. Do you perhaps have a setting to fail builds on warnigns?

dpsutton23:12:10

because those are otherwise benign

kokonut23:12:04

Yep, sounds like plan. I will raise an issue.

Sam Ritchie23:12:13

is it possible to use goog-define to conditionally require or not require some npm dep?

Sam Ritchie23:12:20

I would like to strip this: 

["@cortex-js/compute-engine" :refer [ComputeEngine]]
from require… and then ALSO strip the code in the namespace that uses ComputeEngine… should I remove it from the namespace block and do a manual require?

Sam Ritchie23:12:07

If I do 

(when COMPUTE_ENGINE
  (require '["@cortex-js/compute-engine" :refer [ComputeEngine]]))
Then this later fails: 
(when COMPUTE_ENGINE
  (def engine
    (ComputeEngine.)))
[:clerk] Build failure:
------ ERROR -------------------------------------------------------------------
 File: /Users/sritchie/code/clj/mathlive.cljs/src/mathlive/core.cljs:95:5
--------------------------------------------------------------------------------
  92 |
  93 | (when COMPUTE_ENGINE
  94 |   (def engine
  95 |     (ComputeEngine.)))
-----------^--------------------------------------------------------------------
null
AssertionError: Assert failed: (symbol? module)

Sam Ritchie23:12:21

I guess predictably, I am just not sure how to use this feature to strip out this stuff

thheller06:12:33

conditional requires don't really work

thheller06:12:05

I suggest organizing the code differently so that the "optional" code is in a separate namespace that the user can require if needed