Fork me on GitHub
#shadow-cljs
<
2021-02-18
>
thheller00:02:19

when you require it from the ns :require it will become part of the shadow-cljs build

thheller00:02:33

when you js/require it then it will just resolve at runtime and not be part of the build

bringe00:02:50

Yes, that works. Whereas before I wasn't trying to make shadow bundle things, I later wanted to see if I could get shadow bundling everything as you mentioned in that ticket. I've been reading stuff you said there multiple times and understanding more and more šŸ˜„. > Just stick with :node-library. :esm will not give you any "new" features if it requires post-processing anyways. So until vscode can load ESM directly without further bundling :esm should not be used. I'm sticking to :node-library but was thinking I could still bundle things with shadow if I could make typescript ignore the goog:.. imports, as you mentioned, and then stop using webpack. But I see you mentioned potential issues with that, so I probably will stop this approach now.

thheller00:02:00

yeah I'd recommend sticking with js/require until you get the amount of JS code down significantly

bringe00:02:32

That makes sense

thheller00:02:44

its fine for smaller bits of JS code or JS code that is fully advanced compatible

thheller00:02:05

but for the vast chunk of the vscode based code you probably won't have externs anyways

thheller00:02:04

I mean you can still go with this route and try it

thheller00:02:35

but not many people do so there may be many issues with this that may require tinkering with shadow-cljs

thheller00:02:52

it works ok-ish in the browser but node seems to have some problems

bringe00:02:29

Yeah, I'd rather go the path of least resistance in this case

Kira McLean04:02:29

Has anyone built a custom shadow-cljs build target before? Is this actually possible? I spotted this in the shadow-cljs docs: > The build target is an extensible feature ofĀ `shadow-cljs` but am still looking for details about how it might be done :thinking_face: .. wondering if there are any examples out there

Kira McLean04:02:20

I would like to make a build target that combines devcards and karma (basically combine the current built-in :browser and :karma build targets), so I can use devcards as a test harness for UI-based cljs tests

thheller07:02:53

@kiraemclean I guess as example you could look at the default provided targets, they all use the same mechanism a custom target would use. https://github.com/thheller/shadow-cljs/tree/master/src/main/shadow/build/targets

Kira McLean14:02:37

this is very helpful, thank you for the reply! I didnā€™t know the :karma target could take a runner-ns option, I think that would do it! I was looking at using a custom runner-ns for the existing browser-target then some karma hackery to get it to run in CI, but I think doing it the other way around (starting with the existing karma target and adding a custom runner) would be simpler.

Kira McLean14:02:40

I was wading through the custom targets but didnā€™t figure out how to build a custom one that could hook in to the existing build chain.

thheller15:02:16

they all function based on the same principle. when shadow-cljs finds :target :karma in the build config it'll "expand" :karma to shadow.build.targets.karma/process and call that function for every "stage" of the compilation. https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/karma.clj#L114

thheller15:02:01

so if you were to create a :target :kira you'd create that shadow.build.targets.kira/process function and do whatever you want to do

thheller15:02:55

it it also valid to have :target kira.target which would call (kira.target/process build-state) or :target kira.target/do-stuff which would call (kira.target/do-stuff build-state)

thheller15:02:19

so a keyword is just the shorter version of a symbol or qualified symbol

thheller15:02:01

the function is call repeatedly and is supposed to look at the :shadow.build/stage etc keys to figure out what to do

thheller15:02:58

explaining beyond that will get very technical and it would be best to look at what the current targets do to understand

thheller15:02:13

happy to help if you have specific questions but that should be the rough overview

Kira McLean19:02:32

This is very helpful! Thank you so much for the explanation. I suspect I can acheive what Iā€™m after without needing a whole custom build target, but I see now how itā€™s done.. really really appreciate your guidance, thanks. And also shadow-cljs! Itā€™s very cool.

thheller19:02:50

yeah, I do think that a custom :runner-ns will probably be enough. the important bits there is just the exported init function

thheller19:02:37

I vaguely remember someone doing something with devcards and shadow-cljs before but I can't find it

thheller19:02:56

how you'd hook up devcards to the karma stuff I have absolutely no clue though šŸ™‚

Kira McLean19:02:27

nice.. if I ever get it running Iā€™ll make sure to write it down somewhere šŸ™‚ but yeah all the pieces are here ā€” test harness, karma-compatible test js file, etc. but they donā€™t work together yet.

Kira McLean19:02:28

hah.. yeah Iā€™m on the fence about using devcards as a ui actually.. most front-end browser tests work by appending and removing the component to be tested from the dom. with the dev-card ui Iā€™d have to somehow click around to make sure the right one is showing for the right tests.

Kira McLean19:02:53

anyway.. Iā€™m optimistic about this šŸ™‚ probably will pause to work on something else for a bit to give my brain a rest.. but I really would love to get it up and running! soon.

šŸ‘ 3
Kira McLean19:02:03

thanks again for the pointers.

thheller07:02:56

it is however not exactly documented or easy to do since they can get rather involved in low level stuff (eg. :browser https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/browser.clj)

thheller07:02:23

:karma is much simpler and I think already allows what you are looking for via the :runner-ns option https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/targets/karma.clj

thheller07:02:14

defaults to this one https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/test/karma.cljs and I guess you could just create one that uses devcards instead

bbss07:02:25

I'm trying to put my web-app into an app. I think http://capacitorjs.com looks pretty good so giving that a try. I've built and ran my app successfully, however firebase auth works a bit differently when running in apps (webview). I'm using the capacitor-firebase-auth plugin, but running into an error I haven't been able to solve yet and I think it's related to esModules stuff. The error I'm getting is: āš”ļøĀ TypeError: undefined is not an object (evaluating 'new q.auth.GoogleAuthProvider') Originating here: https://github.com/baumblatt/capacitor-firebase-auth/blob/master/src/facades.ts#L28 I've tried to shadow-cljs release with

:release {:compiler-options {:variable-renaming :off
                             :property-renaming :off
                             :pretty-print      true
                             :source-map        true
                             :infer-externs :auto
                             :output-feature-set :es6
                             :optimizations :simple}}
But to no avail.

bbss07:02:20

Might it be there is a conflicting issue with typescript somehow? There is this comment in the readme:

1 import firebase from 'firebase/app';
         ~~~~~~~~
    8601 export = firebase;
         ~~~~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'allowSyntheticDefaultImports' flag.
If you see the message above, please useĀ `esModuleInterop=true`Ā in yourĀ `tsconfig.json`Ā file.

thheller07:02:26

@bbss and how does the CLJS code looking doing this?

bbss07:02:20

(ns kr.ui.firebase
  (:require ["firebase/auth"]
            ["firebase/analytics"]
            ["firebase/app" :default firebase]
            ["capacitor-firebase-auth" :refer [cfaSignIn]]
            ["firebaseui" :as fbui]))
...

(.subscribe (cfaSignIn "") (fn [u] (js/console.log u :signed-in))) ;;offending line in my code

bbss07:02:15

the library file on github does a require like this: import * as firebase from 'firebase/app';

thheller07:02:59

so (cfaSignIn "") this fails?

thheller07:02:56

did you verify that the firebase version you use matches EXACLTY the version capacitor-firebase-auth expects?

bbss07:02:09

I did not, let me check.

thheller07:02:13

firebase is notorious for changing its API constantly

thheller07:02:26

so I expect that you just use an incompatible version

bbss07:02:38

could be! checking.

thheller07:02:27

for example in the lib there is import * as firebase from 'firebase/app'; but you have ["firebase/app" :default firebase]

thheller07:02:37

those are not the same thing and only one version is correct šŸ˜›

bbss07:02:37

Ugh, they're not the same?

bbss07:02:59

Yeah it's a major version mismatch, the plugin has peerdep 7.x.x and I use 8.x.x

bbss07:02:01

downgrading..

bbss07:02:01

great! updating to that alpha version mentioned in the issue seems to fix it!

šŸ‘ 9
bbss07:02:16

Thanks for the insight @thheller

lambduhhh18:02:35

Does anybody know of an alternative to codox to auto generate documentation for a private cljs project? Codox looks great but seems like shadow w deps isn't officially supported.

lambduhhh19:02:19

(hope I'm posting in the correct place, if anyone knows a better channel to post in just lmk šŸ™‚ )

thheller19:02:47

you can just create a lein project.clj and use codox that way. as far as I know codox doesn't actually compile the code, just needs to be able to read it.

thheller19:02:24

but it has been a while since I used and and only for CLJ at that