Fork me on GitHub
#shadow-cljs
<
2022-02-04
>
Simon01:02:32

Error when running shadow-cljs release app:

Closure compilation failed with 1 errors
--- app/components/user/payment.js:2
Cannot import Closure files by path. Use either import goog:namespace or goog.require(namespace)
payment.js
import { firebaseapp } from 'goog:app.helpers.firebase';
import firebase from 'firebase/compat/app'; <--- error here
import 'firebase/compat/functions';
(...)
(ns app.components.user.index
  (:require
   ["antd" :refer (Avatar Button Dropdown Menu Skeleton Spin)]
   ["@ant-design/icons" :refer (LoadingOutlined)]
   [reagent.core :as r]
   ["firebase/compat/app" :default firebase]
   [app.helpers.macros :refer [if-let-n]]
   ["./payment" :refer (onAuth openCheckout openCustomerPortal onActiveSubscription)] <---- imports
   [re-frame.core :as rf]
   [cljs.core.match :refer [match]]))
Stuck on debugging this. I hope someone can help 🙂

thheller06:02:51

import { firebaseapp } from 'goog:app.helpers.firebase'; should be import firebaseapp from 'goog:app.helpers.firebase';

thheller06:02:34

or probably import firebase_helper from 'goog:app.helpers.firebase'; firebase_helper.firebaseapp assuming thats a def in the ns?

Simon12:02:59

Doesn't work. Same error message. payment.js

import firebase_helper from 'goog:app.helpers.firebase';
import firebase from 'firebase/compat/app'; <-- error points to this line
import 'firebase/compat/functions';

const { firebaseapp } = firebase_helper;
(...)
app.helpers.firebase.cljs
(ns app.helpers.firebase
  (:require ["firebase/compat/app" :default firebase]
            ["firebase/compat/auth"]
            ["firebase/compat/firestore"]
            [app.envvars.core :refer [APP_ENV]]))

(...)


(def ^:export firebaseapp (.initializeApp firebase (if (= APP_ENV "production") firebase-prod-config firebase-dev-config)))

Simon12:02:02

shadow-cljs watch app still works though.

Simon12:02:22

just not able to compile release version

thheller12:02:17

I'm unsure what this might be. what happens if you remove that line?

Simon15:02:16

That worked:white_check_mark: Hehe i don’t know why i included this line. But weird that it fails compilation with it.

Marius14:02:26

Hi all! I just setup TailwindCSS, which is parsing the ShadowCLJS’s app.js to figure out which CSS classes have been used, but can not extract some class names because instead of quotes the app.js contains escaped unicode characters `\x22`  like this: `\x22flex justify-between items-center border-b-2 border-gray-100 py-6 md:justify-start md:space-x-10\x22` . Did anyone experience the same issue?

Marius14:02:08

I found a workaround: Adding an empty space at beginning and end of the class string did the trick. Before: [:nav {:class "hidden md:flex space-x-10"} After: [:nav {:class " hidden md:flex space-x-10 "} @thheller I wonder if there is some setting which would make class names automatically recognizable?

thheller15:02:25

I've never seen that? which is the JS like this?

thheller15:02:36

oh wait you are talking about a development watch build I assume?

Marius19:02:31

yes, exactly

Marius19:02:57

the file is ./target/cljsbuild/public/js/app.js

thheller21:02:46

for development builds the code uses eval to load the sources. thats why you see the \x22

thheller21:02:11

for development you should be pointing tailwind at the cljs-runtime dir. those are normal files with the proper strings

thheller21:02:41

target/cljsbuild/public/js/cljs-runtime that is

thheller21:02:53

for release builds you can point it at just the app.js

isak23:02:59

In our setup we just create the whitelist manually, because last time I checked tailwind / purgeCSS doesn't know about the reagent class syntax. If you use reagent, you'll need to change some values for that to work out too, e.g., w-1.5 -> w-1*5

thheller05:02:28

w-1.5 is not a valid classname. I generally just keep everything in :class "..." and don't use :div.class at all

Marius20:02:43

cool, thanks @thheller for the quick support!

isak15:02:55

w-1.5 is a valid classname, it is just that div.w-1.5 is not valid reagent syntax (that is why we changed it). See the docs here to see w-1.5: https://tailwindcss.com/docs/width

Leif18:02:20

I'm debugging an issue related to :optimize-constants that I think I've bisected down to 2.15.13 (`2.15.12` and before seem to work fine, 2.15.13 and after seem to have the issue). In particular, after 2.15.13, many keyword constants in the code seem to not be assigned. Some keywords (like var cljs$cst$keyword$shouldComponentUpdate=new cljs$core$Keyword(null,"shouldComponentUpdate", "shouldComponentUpdate",1795750960)) are properly created once and all callsites properly reference this global cljs$cst$keyword$XXXXXXXX var, others (like new cljs$core$Keyword(null,"body","body",-2049205669)) are created new every time. Has anyone observed anything similar to this before? Appreciate any help.

thheller19:02:43

@leiferiksonventures is :body maybe only used in one place? maybe the closure compiler is trying to be too smart for its own good?

thheller19:02:20

closure compiler as an optimization might inline the new call to safe the var. that would be my only guess?

Leif19:02:26

@thheller In this case, :body is used 36 times. My most extreme example is :recur (due to plenty of cljs.core.async), which is allocated at 3560 callsites as new cljs$core$Keyword(null,"recur","recur",-437573268).

thheller19:02:43

it should inline all of them but :optimize-constants is not a thing in shadow-cljs so maybe something else is going on?

thheller19:02:09

constants are optimized as a compiler pass during optimizations. not by the cljs compiler

thheller19:02:30

you may also try :compiler-options {:shadow-keywords true}. that optimizes them a little more

Leif19:02:09

Just checked :shadow-keywords and still have the same issue (some keywords are fine, others are repeatedly reallocated). I did see that 2.15.13 bumped the cljs / closure compiler versions (https://github.com/thheller/shadow-cljs/commit/7fefe5b3f604ff11d33539e4899e160dd1ff6eb0) -- maybe that's where the issue lies.

thheller04:02:33

hmm indeed. I also see this now. I'll look into it

thheller09:02:16

should be fixed in 2.17.0. thanks for the report. there really should be a test for this. went unnoticed for too long.

thheller09:02:44

fun thing was that the replacement was working totally fine except that some keywords have a precomputed numeric negative hash

thheller09:02:59

and the compiler pass was only looking for numbers

thheller09:02:32

and some time ago the closure compiler changed how they represent negative numbers in the AST

thheller09:02:54

so some keywords/symbols would still be replaced while others were not

Leif17:04:10

Wow -- excellent. Thank you for the update. Nice find. Tricky bug too.

Leif17:04:28

I also see that the latest version of shadow-cljs fixes the issues I was having with Material UI (that was keeping me on ES5 output v.s. ES6 output). Thank you! Very awesome.

Jimmy Miller19:02:10

So, I am looking at including some cljs in a js web app. I looked at various targets most importantly :npm-module, and :esm. I read a bunch of issues about various tradeoffs. Was unsure what to pick. But a coworker of mine just tried target :browser and loading that into webpack works perfectly fine. Maybe I'm missing it, but it seems like from the documentation that isn't what I'd expect. It seems like those other targets are there to make it work with existing js apps. Now there was one limitation, I couldn't control exports at a fine-grained level, just exporting whole namespaces. Adding a simple little js with some imports and re-exports fixed that all though. So I guess my question is, am I missing something? Is there a reason I shouldn't use target browser + a shim to do this? Is this something that just happens to work but might break in the future? Could target :browser add an exports like esm and make it work with existing js stuff without the nested namespace object?

dpsutton19:02:20

we use :npm-module for metabase. • shadow-cljs.edn: • exported var: • imported into js: • webpack: and

Jimmy Miller19:02:39

Yeah, ran into issues with "goog.promise" is not found that I never dug into on :npm-module. Also the talk of deprecation made me a bit hesitant. Thanks for the links though 🙂

dpsutton19:02:37

yeah i don’t have much more on tradeoffs but if you want to consult how it works for us its all open

thheller04:02:58

:npm-module is best for integration with other tools currently. :browser by default will bundle all JS dependencies on its own in a way that webpack can't see. so you'll end up with duplicated ones such as react for example

thheller04:02:29

although I regret some of the :npm-module design it'll likely stay as is

Jimmy Miller05:02:20

Ahh, got ya. I will definitely try to figure out the issues we were having with :npm-module. Right now, that limitation isn’t too big of a deal for us though, we don’t have dependencies in common with the js project. But that will probably change over time. Glad to hear that :npm-module will stay put. Makes me feel better about using it.

Aleed22:02:12

why do browser builds take so much longer to compile compared to react-native builds? At first thought it was standard cljs->js compilation but if the native builds are much faster for same app must be other reasons

thheller04:02:20

define "so much longer"? browser builds bundle JS so if you include 5000 npm deps that'll take a while. react-native does not bundle since metro will be doing that, so technically you have to add the metro time.

Aleed14:02:09

Oh ok that makes sense. Since react native libraries ship their JS already transpiled. Does shadow cache npm dep bundling or is there concerns against that?

thheller15:02:04

its cached yes

Aleed17:02:55

hm to be clear - i meant on initial build, is the cache used or are packages compiled just incase?

thheller18:02:03

not sure which cache you are refering to. there is none on initial build.

thheller18:02:18

you have given me no data to comment or know what you are talking about

thheller18:02:38

so please provide more data if you have more questions

thheller18:02:01

like actual build time, files in build, etc

Aleed18:02:09

Im not diagnosing a specific issue, was asking a general question. My main q was answered above so thanks, and will follow up w more data if I notice anything that can be fixed

thheller18:02:20

yes, I'd like to answer. but you haven't given me any details on how your build actually takes and if by react-native you mean :target :react-native in shadow-cljs or react-native alone

thheller18:02:58

also you have not defined "so much longer"? what does that mean? for some people 1sec is "so much longer". for some it is 30sec. I don't know and can't answer.

Aleed18:02:22

Yes sorry about ambiguity as I know you're always assisting with questions and lack of context doesn't help. Next time I give my project a run (on mobile now) I'll check and see if anything's worth reporting

Aleed18:02:42

(For above I meant target :react-native versus :browser, yes. Can't remember build times but it was fresh project)

Aron22:02:31

it's javascript