Fork me on GitHub
#shadow-cljs
<
2022-02-06
>
ribelo09:02:14

require() of ES Module /home/ribelo/code/alzey/node_modules/node-fetch/src/index.js from /home/ribelo/code/alzey/build/alzey.js not supported.
this is the first time I have encountered such a problem

thheller09:02:34

thats a node error, not a shadow-cljs error

thheller09:02:05

yeah, it'll become more frequent as more node packages move over to ES. kinda annoying.

ribelo09:02:10

any quick workaround?

thheller09:02:59

"quick" would be changing the node-fetch version to one that has the commonjs files

thheller09:02:15

otherwise there is no "quick" solution, as moving to :target :esm may have all sorts of other challenges 😉

ribelo09:02:49

as usual there's a catch, damn it, I could have been a carpenter

1
Aron12:02:36

or gardener, that's what I would like to be, I could blame the weather for everything

Aleed14:02:44

So latest version of react navigation (for react native) checks whether a component’s fn name is capitalized. The issue is that even if I capitalize the component, the namespace name is being appended. e.g. Home becomes myapp.Home Can anyone think of a workaround for this? Not sure if shadow-cljs or clojurescript handles this, and if proper avenue would be to find a solution in cljs or open up issue / fork library

Aleed14:02:25

for clarity, the problem is that if a component’s name is capitalized, device gets lots of warnings about improper naming

thheller17:02:25

sounds like a question for reagent or whatever other react wrapper you are using

thheller17:02:44

not sure how react-navigation is checking the names. functions don't have names usually.

Aleed17:02:15

I'm using my own wrapper so I have full control. They're checking via fn.name, which is read only, unfortunately. (I'm setting the fn.displayName appropriately)

thheller17:02:35

fn.name won't even exist in release builds so I don't know what this check is supposed to do

Aleed17:02:39

I may open an issue in react navigation to request they check the displayName and fallback to the function name

thheller17:02:06

I know it is a built-in property. Just saying that the closure compiler will optimize that name away. so turns function whatever() to function () if the name is never directly used

thheller17:02:20

since it can't see what react-navigation is using it most likely will optimize it away

thheller17:02:03

checking whether a function name is capitalized sounds absolutely silly to me. can't you just turn off that check? whatever it is meant to do?

Aleed17:02:19

for context. in development this is an example error I see

Got a component with the name 'app$client$mobile$app$register_screen' for the screen 'Register'. React Components must start with an uppercase letter. If you're passing a regular function and not a component, pass it as children to 'Screen' instead. Otherwise capitalize your component's name.

Aleed17:02:30

but yes i agree it’s silly and fix should be with library

thheller17:02:12

and what is that message supposed to tell me?

Aleed17:02:11

oops, it got trimmed. fixed above. they use the check to ensure that a prop is indeed a component, as that is the convention used in js land. the outputted name is akin to the way cljs compiler outputs variables so I know that’s being done somewhere in build process. I was looking to see if there was any hacks to work around this, but i’m going to open issue w react navigation for a proper fix

thheller19:02:49

yeah that seems like an annoying warning. can't think of anything to change this on the CLJS side

👍 1
bringe01:04:29

I ran into this today too. In case anyone else has this issue and finds this, I did this to remove the warnings:

(set! js/console.warn
      (fn [message]
        (when-not (str/includes? message "React Components must start with an uppercase letter.")
          (js/console.warn message))))

thheller05:04:45

ehm doesn't that end in a infinite loop? calling itself all over again? should save a reference to the old js/console.warn somewhere?