Fork me on GitHub
#shadow-cljs
<
2020-09-21
>
Adam Helins07:09:04

Does shadow-cljs have trouble with index.js files? NPM package A (`querystring`) emulates a node module, its entry point is index.js. It is required by NPM package B in my dependencies (`require("querystring")` ). Compilation fails because the compiler cannot find dependency querystring . I, on the other hand, can require it by mentioning (:require ["querystring/index"]) . Indeed, I can fix this by altering altering package B to specify require("querystring/index") but it is a brittle solution at best. What would be a better fix?

thheller08:09:47

@adam678 the correct fix is npm install shadow-cljs in your project. which you should be getting a warning on startup about.

thheller08:09:10

querystring is one of those node polyfill packages which will be installed if you npm install shadow-cljs

Adam Helins09:09:36

@thheller Thanks, indeed it works. However, I don't think there was any warning besides a suggestion to run npm install querystring which didn't do the trick anyway

thheller09:09:13

maybe you are on an older version that didn't warn about this?

Pavel Klavík16:09:57

@thheller I was digging into the first error with reframe.db/app-db and now I have to use (require 're-frame.db) to make it work. What did make this change?

thheller16:09:34

@pavel.klavik I don't understand what you mean. I don't have enough context about what you are doing

thheller16:09:53

makes things a million times easier if you just paste a shadow-cljs cljs-repl app session or so

thheller16:09:15

too many other things may be going when when using nREPL so I need waaaaaaaaaaay more information to provide any kind of help

Pavel Klavík16:09:51

I just checked and no idea how to reproduce it, everything works just fine now

Pavel Klavík16:09:53

recently I am getting more errors of the type posted above, not sure what is causing it, but it is somehow related to code reloading

Pavel Klavík16:09:17

if I get more insight into what could be causing the errors, I will let you know

benny17:09:40

what’s the best way to set up a multi-project repo like so:

project
|-- api
|   |-- src\clj
|
|-- client 1
|   |-- src\cljs
|
|-- client 2
    |-- src\cljs

Pavel Klavík18:09:58

I don't see much value in different directories for clj, cljs and cljc files.

Pavel Klavík18:09:14

I personally have a single src directory with multiple subdirectories which copy my project structure: src/project/client (cljs files) src/project/server (mostly clj files) src/project/common (cljc files) src/project/css (clj files for Garden) and a few others

benny18:09:51

but i ultimately have 3 deployable units, does it still make sense to do it this way though

Pavel Klavík19:09:48

sure, you have three deployable units, but they might share some code (at least we share a lot of code in between)

Pavel Klavík19:09:39

so I would recommend having everything in a single repo (at least till it is possible), and separating everything in build time (you specify the root namespaces and only their dependencies will be included in your build)

benny19:09:43

I currently have one shadow project already (react native) and i’ll have another one (react web) so my biggest problem is the vast difference in dependencies they have and how to manage that

Pavel Klavík19:09:18

As with everything, I would choose the simplest way unless you have a good reason not to. I think we currently have single list of Shadow-cljs dependencies and the right dependencies get picked up during compilation, but maybe some other way is prefered here.

benny19:09:56

ah, true, i recall @thheller explaining that — how only what your used references are compiled

benny19:09:16

i’ll give er a go, thanks @pavel.klavik that gives me the confidence to trudge forward

thheller19:09:56

why do you set it up this way? wouldn't just :client1 :client2 builds be enough?

benny20:09:30

i’m using cursive so loading up the project via lein is ideal and afaik i can’t specify different lein targets with different shadow builds

benny20:09:06

this is ultimately what i’m trying to figure out — what the ideal is all things considered, especially since i’m using lein + shadow

benny20:09:47

right now i have this in the root of my shadow project :lein {:profile "+client"}

benny20:09:59

now i’m introducing another client

thheller20:09:09

if you are using lein anyways then just do whatever you do in lein

thheller20:09:17

you don't have to use the shadow-cljs command

thheller20:09:08

lein with-profiles +client2 run -m shadow.cljs.devtools.cli watch build-id

thheller20:09:28

but you didn't answer why its not just two different builds

thheller20:09:33

why does it have to be lein profiles?

benny20:09:45

because of the different dependencies they have

thheller20:09:59

why is that a problem?

benny20:09:05

but to @pavel.klavik’s point, separating the deps won’t matter much since they’re just pulled in based on usage

thheller20:09:43

exactly. the builds only include what they actually used/required. you can have thousands of extra depenendencies and that won't matter at all

benny20:09:46

so ultimately that’s where i guess we landed — i’ll just use the superset of deps in lein and different builds in shadow

benny20:09:06

sweet, even more confident, thanks guys

wilkerlucio18:09:21

hello, is there a way to increase the timeout of waiting for a REPL command response?

thheller18:09:48

not currently. open an issue please so I don't forget.

3