Fork me on GitHub
#shadow-cljs
<
2020-12-10
>
martinklepsch11:12:33

Would it be possible to write a Closure-compatible JS namespace that merely requires (and exports) a different set of NPM dependencies? I’d like to do this to provide different (API compatible) packages based on node/browser.

martinklepsch11:12:36

I know that shadow can help with it’s :node reader conditional but the issue with that is that that forces the namespace to be .cljc and our code isn’t necessarily valid Clojure (it uses js/ etc)

thheller11:12:27

as long as you don't load that namespace in CLJ thats not a problem?

thheller11:12:02

I don't understand your question though. why would it need to be closure js?

martinklepsch11:12:35

We use linters and other tools that cause trouble in this situation. Maybe we could configure them to only look at things from a CLJS perspective but it also just feels a little… unintended to me to to have a bunch of Clojure namespaces

martinklepsch11:12:02

And Closure JS because my understanding is that that’s the only thing I can load as if it’s a ClojureScript namespace in my ClojureScript code?

thheller11:12:09

I'm not entirely sure what you are asking here

thheller11:12:39

what problem are you trying to solve exactly?

thheller11:12:19

I have seen plenty of projects that use CLJC for everything but only actually working on one platform so its not uncommon

thheller11:12:34

I also wrote this a while ago. while incomplete it may give you an idea how to solve "platform specific" code without relying in compiler hacks

martinklepsch11:12:03

Yeah, for sure. And it’s working. I’m just trying to understand if there might be a different way that would remove the reader conditionals and move the conditional loading into an external file. Maybe I could also just have a designated namespace that re-exports the relevant requires. I guess the effect would be the same as having a Closure namespace.

martinklepsch11:12:10

That said I like the idea of the Closure namespace it would mean we’re closer to “stock” Clojurescript

martinklepsch11:12:11

Just to be clear I’m not trying to solve a pressing problem here I guess. It’s more about exploring alternative approaches to learn

thheller12:12:24

I do not understand which problem you are trying to solve. what does conditional loading mean to you? practical example?

martinklepsch14:12:28

oh that js-options thing actually looks like it might just do what I’m looking for

Ernesto Garcia11:12:16

Hello. We have an existing AngularJS app bundled with Browserify. We have created a re-frame cljs view for to embed in the existing app. Using shadow-cljs, we are able to build into an :npm-module target, and bundle everything together, but we don't have the convenient auto-reload and REPL from shadow-cljs. I would therefore like to target :browser. It can be set up so that shadow-cljs bundles separately from Browserify. How would I achieve bundling all together?

thheller11:12:43

@ernesto.garcia you can use :external an let that file be processed by browserify as usual https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider

Ernesto Garcia11:12:33

I'll look into that. Is there also a way for shadow-cljs to bundle the JS files, and not use Browserify at all?

thheller11:12:09

don't know. haven't looked at angular in a really long time

thheller11:12:24

likely has some browserify plugin to process stuff right?

Ernesto Garcia11:12:59

I think we are not doing any interesting processing, just bundling

Ernesto Garcia11:12:35

Shadow-cljs is able to deal with JS code directly when put in :source-paths?

thheller11:12:52

when its is standards-compliant JS yes

Ernesto Garcia11:12:59

Ok, I will look into your responses. Thanks a lot for your support!