Question

There is an additional target that is intended to integrate CLJS into an existing JS project. The output can seamlessly integrate with existing JS tools (eg. webpack, browserify, babel, create-react-app, …​) with little configuration.

:output-dir	(required) The path for the output files are written to
:entries	(required) A vector of namespace symbols that should be compiled
:ns-regexp	(optional) A regular expression matching namespaces against project files. This only scans files, and will not scan jars.

Example shadow-cljs.edn config

{...
 :builds
 {:code
  {:target :npm-module
   :output-dir "out"
   :entries [demo.foo]}}}

With a JS file sitting in your project root, you may require("./out/demo.foo") to load the CLJS namespace and access it from JS. The JS requires must be the relative path from the JS file location to the CLJS output.

If you plan to distribute code on NPM, then you may want to use the :node-library target instead since it allows for a finer level of control over exports and optimization.

11.1. Working with Optimizations

Unlike the :node-library target, the module target does not know what you want to call the symbols you’re exporting, so it just exports them as-is. If you use advanced compilation, then everything will get a minified munged name!

This is easy to remedy, simply add :export metadata on any symbols that you want to preserve:

(ns demo.foo)
(def ^:export foo 5.662)
(defn ^:export bar [] ...)

This is a standard annotation that is understood by ClojureScript and prevents Google Closure from renaming an artifact. JS code will still be able to access them after optimizations. Without the ^:export hint the closure-compiler will likely have removed or renamed them.

var ns = require("shadow-cljs/demo.foo");
ns.foo;
ns.bar();