shadow-cljs

J 2026-05-20T08:35:22.519159Z

Hi guys! Very naive questions. I have the following code:

(ns foo)

(def h "Hello")

(js/console.log h)
That output to:
var shadow$provide = {};
(function(){
'use strict';/*

 Copyright The Closure Library Authors.
 SPDX-License-Identifier: Apache-2.0
*/
console.log("Hello");
}).call(this);
What is the purpose of shadow$provide = {}? Also is there a way to remove the extra comment?

thheller 2026-05-20T08:46:03.463179Z

shadow$provide is for briding npm deps. guess that could be removed if none are present. feel free to open an issue if you care enough and will never use any npm dependencies in your actual builds

thheller 2026-05-20T08:46:30.038559Z

that extra comment is from the closure library/compiler. dunno if there is a flag to remove it, never checked.

thheller 2026-05-20T08:47:24.569389Z

why do you care though? I mean this is not a realistic use of cljs, just seeing how much it disappears will fail fairly quickly once you actually use the language/datastructures

J 2026-05-20T08:55:38.985969Z

Thanks for the answer. I add some context of a potential use case. Actually, at work I have 95% of the backend written in clj and one project in cljs. There is a node JS project whish is used to serve tracking JS file. Tracking files are stored in a folder (like a resources folder). These files are in JS but written in a way that are difficult to read and maintain. We use uglifyjs next to compact all the files. My idea is to rewrite the node JS project to a simple clj server and all the JS template to cljs (better readability).

thheller 2026-05-20T08:57:51.095829Z

keep in mind that if they make any reasonable use of cljs they'll be at least ~30kb gzipped (cause of cljs.core and the datastructures). since you asked about a few bytes of "dead code" that might be of concern for you

J 2026-05-20T09:10:19.009069Z

Yeah the goal is to use the minimum of cljs.core (or nothing and play only with the js/ interop)

thheller 2026-05-20T09:11:21.434749Z

then I'd recommend sticking with JS. that code is going to be about as ugly as JS only cljs

J 2026-05-20T09:26:25.068639Z

Yeah the only advantage I see (using cljs for js template) is the same syntax than the rest of the codebase.

J 2026-05-20T09:37:37.335119Z

and the macros

thheller 2026-05-20T10:41:46.477949Z

well I'd always use cljs no matter what. but trying to not use cljs.core and avoiding most features sounds painful 😉

borkdude 2026-05-20T11:21:35.976129Z

@jean.boudet11 squint is designed for a problem like this. it is designed to write JS with CLJS syntax while compiling into small output that interops well with other JS files

borkdude 2026-05-20T11:22:39.160259Z

All while being able to use a stdlib very similar to CLJS

J 2026-05-20T11:40:41.617539Z

@borkdude yes I check squint but should I use it in production?

borkdude 2026-05-20T11:54:27.219249Z

well I am and cljdoc is, also https://github.com/nextjournal/clojure-mode/ is using it

J 2026-05-20T12:01:25.085879Z

Ok I will take a closer look