Fork me on GitHub
#shadow-cljs
<
2022-10-24
>
dvingo14:10:01

I have some metadata I include on some function Vars that is only used for development-time tooling. I am wondering if there is a solution to remove this metadata for release builds - would this be possible with a build hook? I was thinking to walk all the namespaces in the build and update the var metadata before compilation. Does this make sense or is there a better strategy?

dvingo14:10:05

answering my own question - unless you explicitly call (meta (var my.ns/a-fun)) the function metadata does not appear to be included in the release builds by default! great!

thheller16:10:44

its not even included in a dev build 😉

😄 1
Lone Ranger18:10:09

Sorry to keep on with this I'm just trying to figure out how to get my intellisense working -- does anyone have any documentation on the import cljs from "goog:cljs.core" style statement? I cannot find anything on this anywhere. Is the goog: part a shadow convention or is that a google closure compiler convention?

Lone Ranger18:10:35

I understand that -- I'm looking for a layer deeper because I'm trying to get the intellisense in my javascript IDE to pick up (compiled) ClojureScript code

Lone Ranger18:10:36

there's no intellisense on cljs when I do import cljs from "goog:cljs.core"; but if I write some "resolve as" code it will work -- just need a few more clues about how it works under thehood

Alexis Schad18:10:23

In the begin of each file there's a call to goog.provide https://google.github.io/closure-library/api/goog.html#provide to create the namespace (with the google closure api)

Lone Ranger18:10:17

hang on -- I think this is talking about something else. I would expect that to be goog.require

Alexis Schad18:10:16

I've just exposed the shadowcljs side

Alexis Schad18:10:56

The goog: part is from google closure api

Lone Ranger18:10:36

I've heard that but I can't find any docs on it

thheller17:10:16

the goog: part is some obscure and mostly undocumented feature in the closure compiler

thheller17:10:44

so I wouldn't expect any tools to support it, neither would I know how to make them

thheller17:10:40

import is ESM and CLJS and the Closure Library use ClojureJS module format

thheller17:10:54

import with goog: is just the way to bridge the two, nothing else

thheller17:10:14

unfortunately its also sort of the only way to bridge it

Lone Ranger18:10:41

I'm assuming it is referencing code the in cljs-runtime directory but it's not obvious to me how

thheller17:10:37

when the closure compiler compiles ESM import files it just rewrites them to remove import and export and instead replaces everything with global references

thheller17:10:54

so cljs-runtime doesn't play a role in this in any way, apart from that being the location where the files end up 😉

MegaMatt18:10:07

I upgraded a project from 2.11.23 to 2.20.5. previously index files in sub directories were respected and after upgrade only the top level index is respected.

public
  index.html
  sub-app
    index.html
any ideas to serve sub-app/index.html when localhost:8280/sub-app url is hit (other than downgrading)?

MegaMatt18:10:59

i initially upgraded because binaryage/oops was complaining about js-fn? not existing. It looks like if i jump to 2.12.7 i fix the binaryage/oops error and still get the same index serving pattern.

thheller17:10:26

I assume you use :dev-http where you can set :use-index-files true to get back the old behavior

thheller17:10:57

so :dev-http {8000 {:root "public" :use-index-files true}}

MegaMatt17:10:38

:builds {:app {:devtools
 {:http-root "public"
                   :http-port 8280
                   :preloads [devtools.preload day8.re-frame-10x.preload portal.preload]}

thheller17:10:43

yeah thats old and deprecated for several years now

thheller17:10:06

:dev-http {8280 {:root "public" :use-index-files true}} at the top level instead

thheller17:10:18

and remove :http-root :http-port from the build config

👍 1