shadow-cljs 2024-01-31 | Slack Archive

witek12:01:29

Hi. I have upgraded shadow-cljs from version 2.25.? to the latest version. Now I get a compilation error: failed to convert sources caused by IllegalArgumentException: CALL 13415:0 [length: 2011] [free_call: 1] [source_file: node_modules/@firebase/firestore/dist/index.cjs.js]. Full output here: https://gist.github.com/witek/00a5669be5821c6d84d7851bcf1a909a The latest shadow-cljs version without this error is 2.26.6. The first version signaling this error is 2.27.1. Any hints how to tackle this problem?

thheller12:01:13

see https://github.com/thheller/shadow-cljs/issues/1170

thheller12:01:30

I'll release a version with a closure compile rollback today

thheller12:01:37

your error looks different, but I'm guessing it has the same cause

witek12:01:51

Thank you!

thheller12:01:09

try if setting :compiler-options {:output-feature-set :es-unstable} makes that error go away also

witek12:01:23

This makes my compilation crash with an other error: Extending an existing JavaScript type - use a different symbol name instead of js/Symbol e.g symbol. This comes from my lilactown/helix {:mvn/version "0.2.0"} dependency.

thheller12:01:58

yes, this is a new warning in the new clojurescript version 2.27 uses

thheller12:01:35

it has been fixed but I don't think there is a new version yet https://github.com/lilactown/helix/commit/35127b79405e5dff6d9b74dfc674280eb93fab6d

thheller12:01:34

should just be a warning though, no crash

sergey.shvets04:02:15

@U2ERGD6UD Have you been able to make it working? I'm having the same issue, but even 2.26.x (tried 5,6,7) doesn't help.

sergey.shvets04:02:45

Looks like some problem with firebase package....

sergey.shvets05:02:47

I've been able to make it work on 2.25.10.

alex18:02:42

I tried setting :compiler-options {:output-feature-set :es-unstable} but am encountering the same issue as @U4EFBUCUE on any shadow-cljs >= 2.26.1. My error also points to Firebase's Firestore package

thheller18:02:22

which version exactly do you use? I reverted that closure-compiler upgrade, so it should be fine?

alex18:02:34

I tried with the 2.26.6, then 2.27.4 - both resulted in similar errors 2.25.10 is the most recent version that works for me

thheller18:02:30

I generally bump version numbers when I change closure versions, so 2.25 -> 2.26 included a closure update

thheller18:02:57

guess something broke there already then. not much I can do about that

witek18:02:05

ClojureScript 1.11.60 and shadow-cljs 2.26.7 works for me. As I remember, I had to downgrade both.

alex18:02:03

Thanks Witek. Unfortunately that doesn't seem to work for me I guess I'll stay on 2.25.10 for now

sergey.shvets21:02:22

Yeah, It's 2.25.10 that is able to compile firebase package. @U05224H0W is there a way to override closure version with shadow-cljs or best practices in debugging what is wrong?

thheller21:02:37

unfortunately that often is not possible, since the closure-compiler keeps making breaking changes to the code

thheller21:02:57

renaming functions and stuff, so a prior version might not work when an old name is used

sergey.shvets21:02:26

🥲 Why would they do that.... Where do I check the closure compiler version the specific version of shadow-cljs uses?

thheller21:02:06

https://clojars.org/thheller/shadow-cljs

thheller21:02:17

listed on the right

sergey.shvets21:02:58

Perfect, thank you so much!

alex21:02:54

One interesting thing is that Witek’s original bug report references a similar Firebase issue but he was able to resolve with 2.26.7. @U2ERGD6UD , which Firebase JS version are you on?

alex21:03:37

@U4EFBUCUE curious if you found a solution or if you’re remaining on 2.25.10

sergey.shvets22:03:21

Hey, haven't had a chance to look for a solution yet. Sticking to 2.25.10 for now.

✅ 1

alex00:05:49

Something changed in 2.28.2, which seems to have unlocked upgrading for us

ordnungswidrig12:01:52

Hi all, I was toying around with libp2p and stumbled over this:

Failed to inspect file
  [...]/libp2p-cljs/node_modules/libp2p/dist/src/libp2p.js

Errors encountered while trying to parse file
  [...]/libp2p-cljs/node_modules/libp2p/dist/src/libp2p.js
  {:line 39, :column 4, :message "'}' expected"}

Where this is the part of the js file:

27	import { DefaultTransportManager } from './transport-manager.js';
    28	import { DefaultUpgrader } from './upgrader.js';
    29	export class Libp2pNode extends TypedEventEmitter {
    30	    peerId;
    31	    peerStore;
    32	    contentRouting;
    33	    peerRouting;
    34	    keychain;
    35	    metrics;
    36	    services;
    37	    logger;
    38	    components;
    39	    #started;
    40	    #log;
    41	    constructor(init) {
    42	        super();
    43	        // event bus - components can listen to this emitter to be notified of system events
    44	        // and also cause them to be emitted

It appears to me that it's because of that new (weird) #foo private member symbols in javascript. How to handle this situation :thinking_face:

thheller12:01:09

unfortunately this syntax is not yet supported by the closure compiler

thheller12:01:04

if you are building for the browser the only option is using a secondary bundler to process the npm files https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider-external

thheller12:01:36

looks like its gonna take a while until closure supports this https://github.com/google/closure-compiler/issues/2731#issuecomment-1915863447

ordnungswidrig12:01:21

I'm still confused about why private fields are suddenly considered a good idea in javascript. But thanks for the information.

thheller12:01:53

well I have that thought about a lot of stuff being added to JS, but ... 🤷

❤️ 1

☝️ 1

ordnungswidrig12:01:56

This is my cljs file

(ns foo.main
  (:require ["libp2p"]))

itaied13:01:33

how can I access __dirname ? targeting :node-script

thheller13:01:21

short answer is don't 😛

thheller13:01:37

js/__dirname otherwise 😛

itaied13:01:02

why not? I'm trying to run an express service for a binary script. I want to load public folder. when working locally, everything works fine, since the main and public are in the same hierarchy. but when packaged, the main is in out which is 1 additional hierarchy When developing locally, it works fine, but when packaged, the

thheller13:01:00

I guess its fine then

itaied13:01:34