How was the :bundle target intended to be used? I have run into some interesting scenarios when interacting with the npm ecosystem and the :bundle target (as have others in the community) so to help myself, and others like me, i'm looking for a little more info into the :bundle target's intended use.
I successfully followed [official cljs webpack guide] and used the [new :bundle target]. Everything worked perfectly.
| (ns app | |
| (:require | |
| [reitit.ring]) | |
| [ring.util.response :as response] | |
| (defn secret-route | |
| [] | |
| ["/secret" {#_ ...stuff}]) |
| ;; Example state | |
| ;; ----------------------------------- | |
| (def stocks-db | |
| {1 {:id 1 :type :asset :parent-id 2} | |
| 2 {:id 2 :type :group :parent-id nil} | |
| 3 {:id 3 :type :asset :parent-id 2}}) | |
| ;; Exammple db state -> tree transform |
I'm experimenting with different ways to organize a Clojure/ClojureScript Monorepo using the Clojure CLI Tools.
NOTE: My monorepo contains CLJ and CLJS projects
I started with [Monorepo Version 1]. Everything worked perfectly. I had to move off this because extra-paths no longer allows paths to specify files outside of the project. Why was I adding :extra-paths from outside my project? My Clojure project in a Clojure webserver. The other project is a CLJS front end app. During dev, I need my compiled CLJS (JS) to be served by my web server (app-server). That's why it had :extra-path of resources and target.
This document now explores the different approaches I found of tackling this issue:
| (ns ^:figwheel-hooks reitit-routing | |
| (:require | |
| [reagent.core :as r] | |
| [reagent.dom :as r.dom] | |
| [reitit.frontend :as rf] | |
| [reitit.frontend.easy :as rfe] | |
| [reitit.coercion.spec :as rss] | |
| [fipp.edn :as fedn])) | |
| ;; State |
| {:closure-defines {your.app/name-1 "some-dev-value" | |
| your.app/name-2 "some-dev-value"}} |
| // step 1 - add below line 350 and verify that this does what we want | |
| if (true){ | |
| newEvent.summary = "I'm BUSY!"; | |
| } |
| ;; API Design Question - Do you like V1 or V2 convenience functions? | |
| ;; ------------------------------------------------------------------- | |
| ;; http clients canbe structured in the following way. There is a | |
| ;; base layer performing low level tasks. In this example, we pretend | |
| ;; its the `request` function below. Then there are conveniences like | |
| ;; `get` and `post` (and so on for the rest of the HTTP methods). The | |
| ;; question is, do people like the callsite of `option 1` or | |
| ;; `option 2`? | |
| (defn request |
| ;; ----------------------------------------------------------------------------- | |
| ;; app.debug_tools.cljs | |
| ;; ----------------------------------------------------------------------------- | |
| (ns app.debug-tools | |
| (defmacro with-fake-log | |
| "Stub console.log to prevent console noise. console.logs will be saved to the | |
| atom provided as the first argument" | |
| [fake-log & body] | |
| `(let [original-log# js/console.log |
| (comment | |
| (require '[reitit.ring :as reitit]) | |
| (require '[ring.adapter.jetty :as jetty]) | |
| (defn health-check-route [] | |
| ["/health-check" | |
| {:get | |
| {:handler | |
| (fn [_] | |
| {:status 200 |