is there a way to force shadow-cljs to output a node script that packages all code and dependencies into a single file? it looks like the default behavior requires me to npm install where i end up running node, ideally i only send a single self-contained file, much like an uberjar

hi everyone. are release artifacts supposed to look for things in /workdir/.shadow-cljs/builds/{{project}}/dev/out/cljs-runtime/?

@levitanong no, that is not part of a release build. note the dev in the path.

@currentoor that is currently experimental and still has a bunch of issues that need to be resolved https://github.com/thheller/shadow-cljs/issues/290

@thheller so this is weird. I’m building a node script, ran a release on it, and when i ran it in docker, it gave me a bunch of errors about not finding '/workdir/.shadow-cljs/builds/image-gen/dev/out/cljs-runtime/goog.debug.error.js'

then you are not using the correct file

a release build will definitely not contain any references like that

won’t a release build simply overwrite a dev build artifact if they have the same name?

yes it would

typically

And i don’t think i’m doing anything weird like renaming things… so I don’t see how i could be using the wrong file

well run shadow-cljs release the-build and look at the output

a dev build can be identified pretty easily it will start with something like

#!/usr/bin/env node
(function(){

var SHADOW_IMPORT_PATH = __dirname + '/../../.shadow-cljs/builds/script/dev/out/cljs-runtime';

a release build will not contain that path and start directly with minified code

ooh, that’s useful. thanks!

I'm trying to use shadow-cljs with https://github.com/juxt/kick.alpha and https://github.com/juxt/edge The issue with the first one: it has a file called injector.cljs that imports figwheel which I don't use and don't have in the classpath. I think shadow-cljs tries to compile every single cljs file on the classpath, and it fails on this one while building the :npm build. Is this really an issue (I haven't gotten the project to work yet, so can't check)? If so, what would be the correct way of fixing it? If not, can I remove the :npm build from the shadow-cljs configuration data to remove the error message? The issue with the second one is that it wants me to add all publicly available web resources to the classpath, including the ones that are generated in target. There are some JS files there as well and because of that, shadow-cljs spams a huge number of warnings about "provide conflict", like provide conflict for #{pathetic.core} provided by pathetic/core.cljs and {"/cljs-runtime/cljs-runtime.pathetic.core.js" #{pathetic.core}}. I think it's possible to fix it by not adding target to the classpath and altering request handlers so that they look there. But to be honest, I have no idea whether that would work with the release uberjar. Another potential way to fix it would be to still have target in the classpath for the server and not have it for shadow-cljs. The only issue here is that I have to write some code to create the correct set of aliases for :deps in the shadow-cljs configuration data, but I think it could be done. But is there another way to solve this that's perhaps more preferable?

@p-himik shadow-cljs only compiles files that are actually required. so injector.cljs must be required from somewhere.

can't find an injector.cljs in the edge repo? ah its in the kick repo whatever that is 😛

@thheller I am trying to use compile-strin bootstrapped clojurescript instead of eval-strand it returns a nullfor a string like "(.log js/console \"HI\")"

Please do try and let me know what you get. I tried the same thing with lein based project and it works, so could it be due to some way shadow bootstraps the compiler?

@metacritical I don't even know what compile-str is so I can't say whats its supposed to return. if you paste the full code I can maybe tell you what is wrong

without any code I can't help

@thheller Well it is supposed to compile cljs to js

It is in the same namespace as cljs.js

https://cljs.github.io/api/cljs.js/compile-str

I think it will be better if i give you the context of what i am trying to do. I am trying to write a electron app that has bootstrapped cljs so that it can eval config files at runtime. but i am unable to get the ambient environment functions when i eval it so i thought i will do a global eval against node ‘vm’ by translating the cljs code to js.

can't say anything about that but I can compile things just fine

(ns demo.bootstrap-script
  (:require
    [cljs.js :as cljs]
    [cljs.env :as env]
    [shadow.cljs.bootstrap.node :as boot]))

(defn print-result [{:keys [error value] :as result}]
  (prn [:result result]))

(def code "(.log js/console \"HI\")")

(defonce compile-state-ref (env/default-compiler-env))

(defn compile-it []
  (cljs/compile-str
    compile-state-ref
    code
    "[test]"
    {:eval cljs/js-eval
     :load (partial boot/load compile-state-ref)}
    print-result))

(defn main [& args]
  (boot/init compile-state-ref {} compile-it))

outputs [:result {:value "console.log(\"HI\");\n"}]

@thheller It's very strange - I can't find it anywhere. The relevant ns is indeed added to the list of preloads but only if I explicitly tell kick.alpha to use figwheel. And there are no messages in the logs mentioning that if was used. Is there any way to find out what exactly has made shadow-cljs compile a particular file?

@p-himik shadow-cljs clj-repl then (shadow/find-resources-using-ns 'that.thing.inector)

but if the edge stuff modifies the classpath or so it may not find whatever is using it

there is this in the repo. not sure what this is about. https://github.com/juxt/kick.alpha/blob/master/src/juxt/kick/alpha/providers/shadow_cljs.clj.txt

I don't know what edge is about or what it needs so I'm absolutely clueless about whats going on

Thanks, I'll try that. The file that you linked is not used because the authors of kick don't use shadow-cljs. I just copied that file to my project and modified it a bit for my needs.

Yeah, of course that call returns just #{}.

you can just replace that file with one that just defines the ns and nothing else

I won't resolve to such easy fixes. I need to know the truth! 🙂 I'll try to dig around for a bit.

well if you do that it will be much easier to find out why it is included

but can you explain a little bit what any of this does?

why are there a billion directories with only one file each?

Ah, gotcha. But I'm almost positive it's injected dynamically in some way. But I'll do that, sure. "Any of this" - you mean kick? Not sure to what directories you're referring.

Still #{}.

if you have a build running that has the empty version injected

open up http://localhost:9630

navigate to the build and recompile it

there is a "Build Namespaces" at the bottom

select the injector and it will tell you how it got included

Oooh, neat! But here's the issue - the problem is only reproducible with the :npm build that's injected automatically. And I don't see this build in the UI. Maybe I can try just copying it so it becomes an explicit build.

For my :main build, there's no injector in the list of namespaces.

ah ... I missed the part where you are using the built-in default :npm build

that indeed does compile everything unless you configure it

so don't use that 🙂

configure it like this

{:npm
 {:target :npm-module
  :entries [your.main.ns]
  :output-dir "node_modules/shadow-cljs"}}

Wait a second, I don't use it anywhere. I have no idea what it's for even - I just copied your code from load-cljs-edn.

that will only include the :entries and their deps

ah now I get it

you are just loading the config and start every build defined in it

yeah don't do that 🙂

Ah, I see! In hindsight, that was kinda obvious and stupid of me. 🙂 Thanks!

what is this kick stuff even for?

It's a build system that should make it easy to automate stuff. E.g. restart your whole build chain and server when you enter (reset) in the REPL. It can also help in situations where you don't want to restart everything, e.g. you need to reload some components without dropping all active connections. But I just started using it and I've never used anything like it before, so I can't really tell you anything really useful about it.

but why would you want to restart shadow-cljs when you restart your server?

they shouldn't be coupled in the first place?

Well, I can add one thing. In my previous project, I had to either specify some paths two times or to parse shadow-cljs.edn within the main code to make the server know about all of the resources. Here, it's launched using the single source of truth, config.edn. It contains everything you want it to contain, and since it uses aero, you can avoid duplication entirely. I need to restart shadow-cljs if I e.g. change a path. In some cases I had to restart it when I added something - don't really recall the details but I think it had to do something with a macros and a new namespace. But I can make it so that shadow-cljs is not restarted if I don't want it to be restarted. And since it's all in the same JVM that's still running, it doesn't take that much time anyway.

Maybe their example will give you a better idea of what it can do: https://github.com/juxt/edge/blob/master/main/resources/config.edn

hmm I see

yeah shadow-cljs isn't really meant to be used that way. the assumption that there is a shadow-cljs.edn and hardcoded and not optional (currently)

so your builds need to be defined in there

everything else is fine

so basically you'll need a shadow-cljs.edn with the builds define like normal

:kick/shadow-cljs
{:build-to-start [:foo :bar]}

you then start those builds in the provider thing

you could define the builds "outside"

but currently there are several things that are tied to the config

Hmm, I thought I could get away with just using (shadow.cljs.devtools.server/start! (dissoc config :builds)) and (shadow.cljs.devtools.api/watch (assoc build :build-id build-id)) while feeding it the config that was preprocessed the same way you do it.

eg. when you edit the config it will automatically trigger a recompile with the new config

you can get away with it to some degree yes

just absolutely not recommended and I make no guarantees that it will work reliably

also how do you do a release build in that setup?

Hmm. But using shadow-cljs.edn again brings that problem of having either to copy some values or to parse shadow-cljs.edn. I'll see how it works out with the common config - maybe that's "some degree" is well within my needs. To be honest, I have never made a CLJ app release, so I'm yet to find that out.

copy which values?

:output-dir needs to be specified for both shadow-cljs and for the server to serve the generated files.

Same with :asset-path, I think.

how often do you change the :output-dir? I haven't changed mine in 4 years 😛

True. But just having it being specified in multiple places makes things harder to reason about, especially when you work with other people and have different projects that use different approaches while still using shadow-cljs. And I don't like to rely on anyone's memory when it can be avoided, including my own. 🙂

I'm trying to understand the architecture. I suppose the main/deps.edn is the primary source for deps

Indeed.

so why not put shadow-cljs.edn right next to that main/deps.edn. make it use :deps {:aliases [:dev]}

and run them separately

or if you really prefer you can run the embedded version just fine

but if you move the config into the config.edn thing I don't understand how you build a release build then?

how is this done for the figwheel sutff?

I can't figure out where the release build happens in the repo?

Since I've never done that before, I'm not really sure what issues you have in mind. In the edge repo they have bin/onejar:

#!/bin/sh

clojure -Sdeps '{:deps {pack/pack.alpha {:git/url "" :sha "0878b52b7718e4b348a500dce0b3edc5b555a4f1"}}}' -m mach.pack.alpha.one-jar "$@"

$ ../bin/onejar -A:prod --args '-m edge.main' project.jar

that seems to be the server side stuff

how is the CLJS compiled in :advanced?

I can see the config but don't quite get how it is built

I certainly hope that figwheel/scss/shadow-cljs aren't running in production servers 😛

That's not my plan, at least. 🙂 Let me see...

so this entire edge architecture commits several sins in my view

how do you even deal with dependency conflicts?

lib.ig.yada/deps.edn
3:        integrant {:mvn/version "0.6.3"}
phonebook-api/deps.edn
6:  integrant/integrant {:mvn/version "0.7.0"}

how does that not get even more out of date the longer the project lives? 😛

why are they spread all over the place 😛

how do you ever audit all deps ...

These pieces are not really parts of the main projects. They're local libraries.

edge.asciidoctor/deps.edn
4:  integrant/integrant {:mvn/version "0.8.0-alpha2"}

And they work like local libraries. And dependency resolution works the same way as it does in Java in general.

ok, I don't have to like it. I can still help you figure out how to best integrate everything

Thank you. I'll keep banging against all the new walls here, and if my head starts to hurt I'll come back.

let me know if you find where the release build for CLJS is produced

so far I can't find it

or the scss for that matter

@dominicm might be able to provide some help fyi

I think I figured it out

Haven't read up, but ask away

The dependency problem is real, but no worse than when you have libraries.

I think the original question was here: https://clojurians.slack.com/archives/C6N245JGG/p1550649905397600

yeah I couldn't figure out how the release build is produced for the CLJS code

but I think its the build alias and the kick oneshot! thing

There's a oneshot multi method for performing production asset builds, the code lives mostly in kick, but has a main in edge under lib.edge.kick iirc

I don't love the production build code yet. So I suspect it will go through some evolutions.

You're right about the reset, but we solve it by only restarting servers if the config has changed.

It used to be a var def'd in a namespace, but that was changed to integrate it with config.edn better.

I think we had some projects where shadow-cljs.edn was not expressive enough for us, and we wanted to use the API and aero tags because of that.

@thheller what would this do in practice? https://github.com/thheller/shadow-cljs/commit/e8ed39ad2081b34f219c74c9c893143c3ee794ea

suppose you have a (:require ["react" :as r]) in your code but don't use it

or only use it on a function that itself was not used

I feel like upgrading shadow from 2.7.29 (?) to 2.8.2 may have broken some of our code

previously react would still be included in the build

but I haven’t pin pointed exactly what

upgrade to 2.8.5

I did

that should fix most of the funkiness

I’m on 2.8.5 now I think

do you use lots of the closure lib stuff?

yeah we’re on 2.8.5 and seeing broken stuff

this is related to jQuery

broken how?

so only in advanced

I haven’t exactly pinpointed what is broken, but I’m getting this error: TypeError: b.modal.modal is not a function

.modal.modal?

where b should be a React component instance, modal a ref

ref to js/$

and modal.modal the Bootstrap modal function

bad naming but this.jqueryref.modal()

basically

ah hmm not sure why that would be different?

me neither but the code hasn’t been touched since March 2018

did you accidentally also update react when upgrading shadow-cljs?

no we upgraded React 2 weeks ago and this worked fine since

given all the version range crap defaults in node and stuff?

hmm ok

this is either (missing) externs or JS deps stuff

did anything change in shadow recently wrt externs?

oh shit

😞

k reverting the PR

do you maybe have some JS requires for only the side effects?

maybe?

oh yeah we do 😄

(:require ["bootstrap"]

hehe oops yeah they will be removed now

for jQuery plugin injection

😄

doh didn't think about that case

hehe doh

so the commit I pointed out is the bad one?

somehow it jumped to sight

yeah

I’m gonna revert and upgrade to the next one once you fix this

thanks for the help

@anmonteiro release is building. give it a min or so. will be 2.8.6

oh kk

ok should be available. sorry about that.

the idea sounded good in my head and worked nicely for the tests I did

just forgot that you may want things only for their side effects 😛

stupid side effects!

so, question about shadow.loader: we are heavily using it in a project to load modules as needed on our web pages. it sounds like 2.8 upgrades GCC which might impact this. anything I should be aware of out of the gate?

no it should work as before

assuming you are using 2.8.6. the previous releases were all bad due to a bad :language-out default

ok. good to know

I tried my best to make it work again. it changed a whole bunch if the closure library but it works fine in all my builds

so it should be fine

we're also currently troubleshooting an issue with IE 11 where a few certain modules just won't load. I'm heading into the office now to investigate 😛 one of the problems we're running into is that it's hard to know why a module might fail to load/run. any tips on how to get more insight into that?

e.g. another issue we had was, a module wouldn't load when cookies was off; turns out it was referring to js/localStorage at the top level and throwing an exception, but we weren't getting any kind of indication that was happening. just the promise returned by shadow.loader never resolved

given the awful state of the IE11 devtools not really

well do you have an error handler attached?

yes

(-> (loader/load "extra")
    (.then fn-to-call-on-load fn-to-call-on-error))

so the second fn is also never triggered?

i'll verify but that's the behavior we were seeing

IE11 also doesn't like console IIRC

only when the devtools are open

yeah I'm exploring that too.

I would expect the loader to properly propagate errors

but who knows

I almost gave up on web dev the first time I had to track down a bug due to that 😛

@thheller btw to make module loading work for us we had to monkey patch google closure

which is… fun

what did you end up patching?

(.setSourceUrlInjection loader false)
         (.setDebugMode loader true)
         (set! (.-usingSourceUrlInjection_ loader) (fn [] false))

we need to force this google.loader.moduleLoader.prototype.usingSourceUrlInjection_ function to always return false

to force the module loader into debug mode

why is that a problem?

otherwise it uses XHR + eval and our content security policy doesn’t allow that

we want it to add script tags to the DOM

interesting

to be clear what we disallow is eval, not xhr

it was actually fun to debug (in hindsight), because our bundles were coming back with status 200 but there was a stupid runtime error from the loader

wonder why there is no built-in flag for this. I'd expect google to also disallow eval

yeah.. I wondered the same

the Closure Library documentation is also not the best

I don’t think many people use it outside Google + ClojureScript

yeah the module loader also now requires a method call that wasn't there previously

not documented at all. fun times.

hopefully fixed in Shadow?

and we can just keep doing what we were doing downstream? 🙂

yeah it injects the needed code

var trustReason = goog.string.Const.from("generated by compiler"); ?

yeah that was a fun one too

uh

I might have to touch that code

so weird. closure library is full of those "safe" constructs to ensure things are "trusted"

I really wonder how google injects the module loader config

is setModuleUris not there anymore?

nope its gone

😞

we’re monkey patching that code too

setModuleTrustedUris now

to add the CDN prefix for our modules

don't monkey patch stuff. just tell me that you need a setting for something 😉

but :asset-path takes care of that no?

then we need to be able to prefix the module URIs with the CDN path

we don’t know it at compile time

it’s a chicken-egg problem

we need to compile the CLJS for Buck to output the compiled hash

that’s how we guarantee we don’t do work if nothing changes in our CLJS

the hash stays the same

in fact, our server “tells” the HTML what the CDN asset path is

so I’m currently doing:

(->> (js/Object.keys old-uris)
              (run! (fn [k]
                      (let [links (->> (gobj/get old-uris k)
                                       (map (fn [path]
                                              (build/static-url path)))
                                       into-array)]
                        (gobj/set uris k links)))))
         (gobj/set js/goog.global.shadow$modules "uris" uris)
         (js/shadow.loader.mm.setModuleUris
          (gobj/get goog.global.shadow$modules "uris"))

you can use :module-loader :no-inject so it doesnt inject the shadow$modules variable

which you can just set via HTML instead for example

having a way to not do this would be appreciated, but it’s not a strong need from our side

ah, interesting

the user guide only mentions :module-loader true 😛

yeah its well hidden 😉

basically the build output generates the module-loader.edn file (or .json)

you can use that data. rewrite it and emit in into html

<script>var shadow$modules = <the-json>;</script>

somewhere before the JS include

https://github.com/thheller/shadow-cljs/blob/f396caecf908b3e135a58f1af5aa433b1ce19326/src/main/shadow/build/targets/browser.clj#L654-L658

I've done this in the past but stopped caring about busting caches along the way

but yeah there had to be a different way of getting that info there

since adding the hashed urls to the file changes the hash of that file 😉

what does “inject the loader data” mean?

inject the shadow$modules var into the code (was shadow$loader previously, renamed because of a weird renaming bug)

hrm so ideally I’d like something in the middle

like what?

like, a function to map over the URIs and prefix them 😛

but I might be asking too much

it’s OK to say no 😛

so you only know the prefix at runtime not at build time?

also, it might be that the deploy hasn’t fully completed, but I’m seeing the same runtime error with shadow 2.8.6

yeah I only know the prefix at runtime

in the JS thing

@thheller yeah 2.8.6 didn’t fix our thing

reverting to 2.7.29

what is the problem?

same one

modal.modal thing

hmm odd

agreed

the code removal is definitely disabled

this could be between 2.7.29 and 2.8.X

I don’t have too much insight into what the problem would be

hmm if you handle the caching and stuff it might be the new minimize-require default

that will definitely break if you use files from different builds together

what’s that

caching is definitely sorted out

https://clojureverse.org/t/reducing-the-build-size-when-using-lots-of-js-dependencies/3742/2

I enabled that by default

😄

k trying

:js-options {:minimize-require false} to disable

trying that now

@thheller wait so, minimize-requires is disabled in dev, and enabled in prod?

yes

no need to optimize for size in dev builds

so would it also break in bad ways if I enabled it in dev?

to experiment

no its fine, just causes some additional recompiles if your JS deps change

I mean, assuming that’s what’s breaking our bundle

would it be repro’ed in dev?

hmm it might?

trying

shadow-cljs takes extra care to ensure everything is recompiled and invalidated correctly

but I'm unsure what all your buck stuff does so maybe it decides to not recompile something when it should?

I don't know 😛

hm

in dev we don’t have buck

so it’d be shadow all the way

yeah then it will probably work

Is the --npm flag actually used? I can't find where it's handled.

no it just tells the server that it was started by the npm script

doesn't have any effect on builds and stuff. I think the only case that actually used it was removed a while ago

OK, good. I was starting to think I'm becoming blind. 🙂 So, an interesting thing. Right now kick only supports figwheel. And both release build and debug watch are ran with explicitly specified :source-paths. The reason is that the output dir inside target is added to the classpath - I think just to make the server aware of the resources there during the runtime. But when you specify {:deps true}, shadow-cljs ignores :source-paths. I can fix it in my project by explicitly specifying a filtered list of aliases for :deps (the directories inside target are added to the classpath by dedicated aliases). But would be interesting to know if there's a better way.

uhm I don't follow

you can't add :source-paths dynamically

Well if I use shadow-cljs dynamically then I can change anything. But not when {:deps true} is set, yes.

I'm confused. you cannot change the :source-paths once the JVM is running

figwheel isn't actually changing source paths, it is changing input paths

different things

:source-paths in figwheel are used as inputs to the CLJS compiler

so the JVM doesn't know about them

meaning they can't contain macros

which I found profoundly annoying

or I'm completely missing what you are talking about ... also possible.

Ohhh. So when I use shadow-cljs by using server/start! and api/watch, I'm reusing the classpath, and none of :deps, :lein, :source-paths (and probably other keys) are in effect.

correct

they only apply when shadow-cljs is started

when you use the embedded mode they have no effect at all

and just use the classpath you are on

Damn. So I cannot add target to the classpath at all. Hence, I must have an additional static files handler that looks specifically under target.

who uses target? why do you need it on the classpath?

The edge project has the server set in such a way so that the one and only static files handlers looks for files only in the public directory inside any of the classpath paths. resources is on the classpath, so resources/public is used for some regular static files. target/dev or target/prod is also on the classpath, so target/{dev,prod}/public is used to serve some generated static files. At least, that's my understanding.

@thheller :minimize-requires false still makes it break

does your dev build work with 2.8+?

yeah

I’m on 2.8.6

hmm

@thheller I’m bisecting locally but there might be a change this was introduced between 2.8.2 and 2.8.5

2.8.3 changed shadow$loader to shadow$modules so with your hack active that will break depending on which one you rewrite

we don’t have modules in production yet

hmm so its just missing the boostrap stuff? thats weird

I don’t know what’s happening

but our upgrade from 2.8.2 to 2.8.5 is what broke it 100%

wait I thought all 2.8 releases broke? you downgraded to 2.7.x?

this may cause all sorts of weird issues

https://github.com/thheller/shadow-cljs/commit/2d4d49d70fc03781763b631f1ecbf84023238588

maybe try :language-in :ecmascript6?

don't set :language-out :ecmascript6 or higher as certain optmizations don't yet work with es6+

could try less though

need :language-in es6+ since closure library now contains es6 code (eg the new module loader stuff)

trying language-in

ok so it isn’t language-in either 😕

the only other commit that stands out to me is https://github.com/thheller/shadow-cljs/commit/e8f85964bebbcd830f81514b203dd47038815f4d

@thheller does this commit look fishy to you ^ ?

no?

looks like it does exactly what it should?

so state is being updated to just contain :virtual?

I might be ways off, but it looks weird

virtual sources are generated by the compiler and should not be compiled by closure

all the other commits in the version range look fine to me

oh I get it

->> got me

its just copying the source to :output without compiling

but that code isn't used in :release mode at all anyways

kk

I’ll try 2.8.3, and 4

see which one is broken

we’re currently running 2.8.2 in prod and all is fine

2.8.5 and 2.8.6 are broken for us

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/compiler.clj#L1220-L1225

what about this?

:release doesn't call convert-goog only :dev does

otherwise the closure lib files got converted twice which worked but produced annoying warnings

I’m not sure what that means

converted twice because Closure’s last pass would also convert them?

closure started including files that can't be loaded like the other closure files in dev mode

so they need to be converted in dev to something that can be loaded

in release mode that would lead to compiling the files twice, once for the conversion and once for the optimizations

eg. this can't be loaded without processing first https://github.com/google/closure-library/blob/master/closure/goog/loader/activemodulemanager.js

but I don't see how this is related to your problem

but there haven't been many commits since 2.8.2 so I don't know whats up

did you try a release build without buck?

just to rule out issues there?

we’re not using code splitting in these builds

I really don’t think Buck is the problem here

we’re only using it to know where targets should be output to

shadow is still in control

we’re literally calling (shadow/release* build-config {:verbose true})

hmm ok

did you try 2.8.3/4 yet?

trying 2.8.3 now

the feedback loop is a little slow for this

so 2.8.3 is broken

therefore there are only 2 possible commits that could have done this 😛

and we’re not using code splitting so I don’t think it could’ve been the loader -> modules one?

depends on whether your do anything with shadow$loader?

can't see how that would possible affect a missing bootstrap .modal either

and you are sure 2.8.2 is working and wasn't just a fluke?

100%

so you require "jquery" and "bootstrap"? maybe I can reproduce something on my end

ugh

I don’t think I can produce a minimal example easily

did you try logging whatever b was in b.modal.modal?

haha

I can actually reproduce it

😮

just include jquery and bootstrap

(ns cljsjs.ajquery
  (:require ["jquery" :as jquery]))

(js/goog.exportSymbol "$" jquery)
(js/goog.exportSymbol "jQuery" jquery)

in release mode the .modal is gone

this is our jquery shim

ok nice

that you can repro

I wonder if $ is being mangled so some thing?

["jquery" :as jq]
    ["bootstrap"]
    ))

(js/console.warn "modal" (.-modal (jq "#app")))

undefined in release

@thheller wait so if you revert https://github.com/thheller/shadow-cljs/commit/e8f85964bebbcd830f81514b203dd47038815f4d

does it work then?

it does not

I'll bisect a bit

thanks

gah I'm an idiot

no idea why 2.8.2 still worked for you. the first commit you linked is responsible

https://github.com/thheller/shadow-cljs/commit/e8ed39ad2081b34f219c74c9c893143c3ee794ea

I only disabled half of it .. the code that actually removed the require call was still being used

should work again in 2.8.7

thats what I get for working on 2 things at once 😛

hahaha

thanks

@thheller confirmed fix in 2.8.7