Fork me on GitHub
#shadow-cljs
<
2023-06-19
>
thheller06:06:49

probably better ask in #C03S1KBA2 or #C03S1L9DN? doesn't sound like a shadow-cljs question

Alex H10:06:39

Hi folks - is there a way to output a standalone node-script with macchiato? It uses these unhelpful (node/require "http") (where node is cljs.nodejs), that seem to be output verbatim by shadow-cljs. Can I somehow get those to bundle the req's properly?

thheller10:06:29

"http" is a node built-in package? isn't never be bundled regardless?

Alex H10:06:19

bad example - it does the same with some npm modules, such as cookies, ws, etc.

thheller10:06:00

never looked at macchiato? can you point me to the sources? is there any particular reason they are doing this instead of just over the ns form?

Alex H10:06:15

it does that for a whole bunch of npm deps

Alex H10:06:51

I've been wondering whether I should just "fork" macchiato and replcae them all with the ns form. Just trying to avoid the work if at all possible.

hifumi12310:06:36

I've used macchiato-core with node-script just fine. What specific errors do builds give you?

Alex H10:06:02

It builds & works fine, if the npm modules are available. But it isn't standalone - you need to install certain npm modules.

hifumi12310:06:23

That's because macchiato-core depends on external node modules

hifumi12310:06:40

i.e. it doesnt use just the node stdlib

thheller10:06:46

(ns macchiato.cookies
  (:require
    [cljs.nodejs :as node]))

(def ^:no-doc Cookies (node/require "cookies"))

(def ^:no-doc random-bytes (node/require "random-bytes"))

thheller10:06:59

what is the reasoning to write it this way?

Alex H10:06:19

> That's because macchiato-core depends on external node modules I'm aware, but shadow-cljs can normally bundle things just fine

thheller10:06:42

(ns macchiato.cookies
  (:require
    ["cookies" :as Cookies]
    ["random-bytes" :as random-bytes]))

Alex H10:06:44

> what is the reasoning to write it this way? beats me - really weird.

hifumi12310:06:48

I see. I’ve personally never gotten node scripts to bundle everything into a single file. I’ve always assumed npm install was necessary to run scripts using libs beyond the stdlib

thheller10:06:56

that should be fine with regular CLJS as well

hifumi12310:06:07

re: macchiato: IIRC macchiato was written when people were still using lein-cljsbuild and NPM support was shoddy at best with existing tooling (mostly cljsbuild and figwheel)

thheller10:06:22

time to fix that then I guess 😉

Alex H10:06:41

Yea, I'll probably do that - just make my own macchiato copy with those things changed to the ns form.

hifumi12310:06:00

You can find use of require in let forms, which I find pretty ugly. I’ve never bothered sending PRs fixing them because in the end macchiato-core has more or less “just worked” for me. And the repository itself doesnt seem maintained.

thheller10:06:03

I have no other suggestion to make, there isn't an easy way to bundle things hidden from the bundler like that

👍 2
hifumi12310:06:57

@Alex H With that said… if you’re willing to fork macchiato-core, I’m willing to help maintain it, since I have some projects that rely on it for SSR with React

Alex H10:06:05

I've submitted a PR upstream: https://github.com/macchiato-framework/macchiato-core/pull/53 In the meantime, I'll just use my own fork as a git dep.

Alex H10:06:19

I have no plans of maintaining it in any meaningful way, FWIW - just the bare minimum that works for me.

Alex H06:06:15

FWIW, the PR above is now merged upstream, and also available on clojars from 0.2.24 onwards.

👍 6
greg20:06:47

If shadowcljs uses cljs 1.11.57, does it mean I'm implicitly using 1.11.57 as well? Or is it only version shadowcljs is built with?

greg20:06:44

Question about using deps aliases with shadow: I'm using nubank/workspaces and I would like to move that dep to a deps.edn alias, e.g. :ws alias. My shadow-cljs takes deps from deps.edn. I know I can provide list of aliases to shadow.cljs under :deps ins shadow-cljs.edn. Is it possible use such a :ws alias during shadow-cljs watch, but not during a release?

hifumi12321:06:14

You use the CLJS and google-closure-library bundled with Shadow, correct. Similarly, other libraries (like core.async) have implicitly fixed versions to ensure nothing about shadow breaks The exception to this is if you set :lein true or :deps true, which in case you are solely responsible for providing dependencies that work with shadow (e.g. if you pull in a newer clojurescript than what your version of shadow-cljs depends on, then you may unknowingly break shadow)

👍 2
til 2