shadow-cljs includes everything you :require in the ns forms, thus you need to remove the require to get rid of it?

Thanks @U05224H0W for your quick response. I cannot remove that because it is required for one of the backend service

And I want to exclude it in shared.js, because it is not needed in client side

then you may need to split a namespace that contains the backend code into one that is one included on the backend and one that contains the client side

if the code is not needed it should not be required

or are you asking about a specific npm library?

I was facing issues with https://www.npmjs.com/package/aws4-axios. I too have other npm modules such as axios, Luxon etc, there are fine.

FYI, I have separate name space for UI and Server

in general server side code should just not be included in a client side build. your namespaces should be structured accordingly

and only your namespace :require controls what is included, so thats what you need to work out. can't give many tips besides that

you can disable the inclusion of certain npm packages via :js-options {:resolve {"package-you-dont-want" false}} but that won't affect the CLJS code getting included

so best option is clearly structuring namespaces so certain stuff just isn't required in the first place

Sure I will re-check the structure

just to confirm: you are not using :modules and a single build to compile client and server code together? so you don't have a :shared module and then a :client and :server?

I do have :shared module for client. For server we have separate build. Please find the shadow-cljs.edn file

ok, that should be fine

FYI you do not need :entries [our-app.ui.pages.getting-started] if :init-fn is the same namespace. :init-fn desugars to that :entries, so specifying it again is redundant. just :init-fn is fine.

Great @U05224H0W. It worked. I appreciate your help. Thanks

I think you're right. It was described as being the same as the "renderer" but runs with more permissions. I first tried :target :browser but had some trouble and then found https://clojurians.slack.com/archives/C6N245JGG/p1634150800435700 thread. I'll try :target :browser again since now I don't remember what the problem was.

yeah :node-script really assumes node and at least watch/compile builds will probably only run in actual node

:target :esm might also be an option. last time I looked at electron it didn't support ESM but its been a while

I don't get results in https://grep.app/search?q=exposeInMainWorld&filter[lang][0]=Clojure and I haven't found examples e.g. https://github.com/logseq/logseq/blob/master/resources/js/preload.js just does it in javascript. I tried adding a new browser target

:preload {:target :browser
                    :devtools {:watch-dir "resources/public"}
                    :output-dir "resources/public/js/preload"
                    :asset-path "js/preload"
                    :modules {:preload {:entries [app.preload.core]
                                        :init-fn app.preload.core/main}}}

          :renderer {:target :browser
                     :devtools {:watch-dir "resources/public"}
                     :output-dir "resources/public/js"
                     :asset-path "js"
                     :modules {:renderer {:entries [user]
                                          :init-fn app.renderer.core/start!}}}

:renderer {:target :browser
                     :devtools {:watch-dir "resources/public"}
                     :output-dir "resources/public/js"
                     :asset-path "js"
                     :modules {:shared {:entries []}
                               :renderer {:entries [user]
                                          :init-fn app.renderer.core/start!
                                          :depends-on #{:shared}}
                               :preload {:entries [app.preload.core]
                                         :init-fn app.preload.core/main
                                         :depends-on #{:shared}}}}}

Unable to load preload script: C:\Users\richie\Documents\org\projects\electric-clj-play\resources\public\js\preload.js
ReferenceError: SHADOW_ENV is not defined
Uncaught ReferenceError: SHADOW_ENV is not defined

:target :esm didn't work right away although now I can't remember what was wrong... shoot.

Aww man. When I started out, it was working but had warnings. Now, it's broken and I can't make it work at all. I'm sad. I think I'm going to give up on electron.

if you want to setup a repo with the failing setup I can probably tell you where the error is

I tried to get everything back to where I think it was when I started. The time where I was just complaining about warnings. Now I have ReferenceError: __dirname is not defined coming from the preload.js file. https://github.com/rgkirch/electron-help Thanks a million! My goal was to add a second electron window to help debug things. I have some tracing in my main app that I wanted to send over. Initially I assumed they'd share my global state but it looks like I have to use ipc.

Alright. I must have had nodeIntegration enabled. e.g. :webPreferences {:nodeIntegration true I'm back to just having the warnings. That means I just don't know the "right" way to do this since I'm override the default behavior and what I'm doing here is discouraged for security reasons.

I feel a little better though.

After I got discouraged I started reading the docs on cljfx but I might keep trucking with this for a bit. Since :target shouldn't be a :node-script, do you have any suggestions on how to make it work as :esm or :browser? Thanks again!

I tried :esm https://github.com/rgkirch/electron-help/compare/master...target-esm. I get SyntaxError: Cannot use import statement outside a module.

https://github.com/thheller/electron-cljs

I setup a full repo with a working setup

yours had a little too much extra chaos in it 😉

I misunderstood this comment. I read it as suggesting either :target :browser or :target :node-script with :js-options {:js-provider :require} I tried

:preload {:target :browser
                    :devtools {:watch-dir "resources/public"}
                    :output-dir "resources/public/js"
                    :asset-path "js"
                    :modules {:preload {:entries [app.preload.core]
                                        :init-fn app.preload.core/main}}
                    :js-options {:js-provider :require}}

          :renderer {:target :browser
                     :devtools {:watch-dir "resources/public"}
                     :output-dir "resources/public/js"
                     :asset-path "js"
                     :modules {:renderer {:entries [user]
                                          :init-fn app.renderer.core/start!}}}

to do what exactly?

(:require ["/my/awesome/stuff" :as awesome-stuff]) Previously I'd been using figwheel with webpack to make an index.bundle.js and then

(:require awesome-stuff)

// index.js
awesomeStuff = require('src/js/my/awesome/stuff.js')
window.awesomeStuff = awesomeStuff

this is way better

well, they are not really solving the same problem

Ok I think this question resolves to “how does goog.require work “

your description is somewhat hard to understand

> import {Config} from "../config"; // this explodes in the browser

what does "explodes in the browser" mean?

if shadow-cljs compiles this code it'll never get to the browser in that shape?

(def ^:export Config app-config/Config) why is there an ^:export?

import config from "goog:app.lib.ext.config"; why is this importing the CLJS ns instead of just the config directly?

why is config JS in the first place?

so many questions 😛

goog.require is no-op and does nothing at runtime. it merely serves as static information for the compiler so it can sort sources in the proper order

it serves no other purpose in shadow-cljs. in regular CLJS it is used by the debug loader and actually does something, in shadow-cljs it does not since it uses its own loader.

Sorry, yeah I know it’s confusing I wasn’t sure how much info to include

In the browser that JavaScript expands to ”/app/config”

the import statement

here's what the error looks like, expanded:

Uncaught (in promise) ReferenceError: Config$$module$app$config is not defined

I should also add this is executing in a webworker context

when I set a break point it still comes up as undefined which is odd considering the import seems to be working

I'm wondering, should

"/app/config.js"

"/js/compiled/cljs-runtime/app/config.js"

I don't know what this output is. it is not output of a shadow-cljs build

and no, it should not expand that "/js/compiled/cljs-runtime/app/config.js"

in fact there should not be any import anymore whatsoever

so I'm not entirely sure what you are doing but the code you showed is not generated by shadow-cljs

If you don't think this is insanity I can DM you some more detailed code, it's company code so I can't really put in public chat. But here's the setup: • shadow-clj project • three typescript files, (config module config and module that calls a webworker, thread-utils) and (webworker worker) ◦ thread-utils depends on config (this is where the error is happening) • tsconfig file that compiles the typescript into a location in src/gen • shadow project builds :main, :base, and :worker • clojurescript code from :main calls thread-utils from src/gen • crash

so you are right that shadow-cljs is not generating the javascript

the generated javascript from the tsconfig is being called with

(:require ["/classpath/to/thread-utils" :as thread-utils])

(thread-utils/testAdd)

I realize this is insanity, yes.

mostly I'm trying to localize if this is a google-closure-compiler issue, a misconfigured typescript issue, or a misconfigured shadow-cljs issue

so what does the JS file header look like after ts is done with it? just the import statements is fine

so the actual file shadow-cljs is importing in src/gen I guess

TS might not like the absolute includes, so instead try relative ones. so just ./config.js if they are all in the same dir

I'm really only guessing here. I do not understand your setup, so my guesses will not be very accurate or helpful

ok just to close the loop, the error was very strange

// case1.js
export class Config {}
Config.fooPath = Paths.foo
Config.barPath = Paths.bar

// case2.js
export class Config {
   fooPath = Paths.foo
   barPath = Paths.bar
}

import {Config} from "/path/to/config";

// case1.tsx
export class Config {
   static readonly fooPath = Paths.foo
   static readonly barPath = Paths.bar
}

// case2.tsx
export class Config {
   fooPath = Paths.foo
   barPath = Paths.bar
}

The only thing I can think of here is that since the export is declared in the generated code before the static methods are added, the static methods are not exported

so it wasn't a config error at all, just a masking bug

> :pretty-print and :pseudo-names default to false. You can use shadow-cljs release app --debug to enable both temporarily without touching your config. This is very useful when running into problem with release builds from the https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options Information about https://clojurescript.org/reference/compiler-options#pseudo-names

there is also shadow-cljs release app --pseudo-names, which is without source maps. sometimes some optimizations make the source maps inaccurate and confusing. then its just better to decipher the generated JS, which pseudo names make possible somewhat

I thought i remembered that being an option but didn't see it in the users guide. The only mention of pseudo names was what i found unless i missed a reference