This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-10
Channels
- # adventofcode (174)
- # announcements (5)
- # aws (9)
- # babashka (17)
- # beginners (259)
- # boot-dev (1)
- # calva (6)
- # cider (19)
- # circleci (7)
- # clj-kondo (9)
- # cljfx (51)
- # cljs-dev (4)
- # clojure (83)
- # clojure-australia (2)
- # clojure-dev (9)
- # clojure-europe (78)
- # clojure-nl (3)
- # clojure-spec (4)
- # clojure-switzerland (1)
- # clojure-uk (18)
- # clojurescript (22)
- # conjure (17)
- # cursive (17)
- # data-science (1)
- # datomic (15)
- # defnpodcast (1)
- # events (2)
- # fulcro (39)
- # graalvm (16)
- # graphql (1)
- # kaocha (5)
- # lambdaisland (11)
- # malli (6)
- # meander (1)
- # off-topic (26)
- # pathom (10)
- # re-frame (10)
- # reitit (6)
- # rewrite-clj (7)
- # sci (3)
- # shadow-cljs (28)
- # sql (12)
- # test-check (10)
- # tools-deps (31)
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.
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)
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
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?
I have seen plenty of projects that use CLJC for everything but only actually working on one platform so its not uncommon
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
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.
That said I like the idea of the Closure namespace it would mean we’re closer to “stock” Clojurescript
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
I do not understand which problem you are trying to solve. what does conditional loading mean to you? practical example?
isn't control via the build config enough? https://shadow-cljs.github.io/docs/UsersGuide.html#js-resolve
oh that js-options thing actually looks like it might just do what I’m looking for
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?
@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
I'll look into that. Is there also a way for shadow-cljs to bundle the JS files, and not use Browserify at all?
I think we are not doing any interesting processing, just bundling
Shadow-cljs is able to deal with JS code directly when put in :source-paths?
Ok, I will look into your responses. Thanks a lot for your support!