I need to (conditionally?) import a polyfill to support a JS library (react-boostrap, sigh, doesn’t work on IE11). Needs Object.assign. Is there a recommended way to do this with shadow-cljs/clojurescript? Should I load it conditionally directly in the HTML?

There’s more to this — I actually need to make sure to load some polyfills before any 3rd-party code is loaded. I’m using for now a http://polyfill.io script element, but I would prefer if the contents of the returned polyfill to be prepended to my final bundled file, but without passing through google closure optimizations at all.

@orestis you can set :compiler-options {:language-out :ecmascript3} and it should add the closure polyfill for that

I’m writing an issue about it since it seems to be more complicated than that (due to Closure polyfill and React weird interactions)

alternatively you can set :compiler-options {:closure-injected-libs #{"util/assign"}}

Is it language-out or :output-feature-set

for this part :language-out is probably better

note that this only really applies to release builds so if you are testing with development builds that may not work

https://github.com/thheller/shadow-cljs/issues/468

but since its fairly common for JS libs to unconditionally ship their own polyfills you may end up with multiple versions and the same polyfill

which may not work

Yeah that’s extremely annoying. I see for example that react-bootstrap depends on babel runtime…

I need it for development as well — our designers need to be able to test in IE11 while in dev mode to fix CSS and other things.

I would honestly recommend keeping the polyfills as a separate script element which you can make conditional for only IE

@orestis in the github issue please provide at least some source reference on how I would reproduce the problem

which npm module (+ version) to include and so on

Oh sorry. Doing this right now.

also the actual error you run into

I know it sucks extracting that for IE ...

Do you prefer a sample project? Or just library versions etc?

sample project would be great

Let me see how minimal it can get.

make sure you have the correct versions installed

there might be some version conflicts

please check which version is in node_modules/@babel/runtime/package.json

should be "^7.3.4"

Made a minimal repro here: https://github.com/orestis/shadow-polyfill-issue

Obviously has to be tested with IE11

Thanks so much for taking some time to look into this. It’s not a high priority for me, so please don’t feel any pressure at all.

:compiler-options
        {:rewrite-polyfills true
         :language-out :ecmascript3}

this works in release mode

Thanks! Checking with the actual app to see.

Can I nest compiler options under “release”?

sure but that doesn't matter as those only apply to release anyways

will have no effect in dev

Doesn’t seem to fix the problem for the actual app… making sure I actually have the correct things.

No luck 😞

There might be other things in my actual application that trigger this in other ways.

I made this demo ns

(ns 
  (:require
    ["react-bootstrap" :as bs]
    ))

(defn init []
  (js/console.log js/Object js/Object.assign))

it loads fine in IE11 when the :compiler-options set

fails with the .assign error if not

;; shadow-cljs configuration
{:source-paths
 ["src/dev"
  "src/main"
  "src/test"]

 :dependencies
 []

 :dev-http
 {9005 "public"}

 :builds
 {:app {:target :browser
        :modules {:main {:init-fn }}
        :compiler-options
        {:rewrite-polyfills true
         :language-out :ecmascript3}
        }}}

again only in shadow-cljs release app

Ah, but that doesn’t exercise the code inside react-bootstrap, it looks?

not for compile or watch

yes, but the error you posted happens during load

if you get past the load stuff then its probably a different error

That’s true, in release mode the error happens during load. In dev mode it’s shadow catching the error and reporting it.

just forget about development mode for now

only interested in release as that is currently the only thing that can potentially work

dev is busted and won't work regardless

I’ll see about my minimal repro in release mode and report back after lunch. Thanks for looking into this!

@orestis it works if you set :js-options {:rewrite-polyfills true} + the :compiler-options

even seems to work in dev mode

:js-options
         {:rewrite-polyfills true}
         
         :compiler-options
         {:language-out :ecmascript3
          :rewrite-polyfills true
          :infer-externs :auto}

it worked in my test since I used Object.assign in the CLJS sources which caused the polyfills to be added

but the JS sources are processed in a separate pass so it must be enabled there manually

Can confirm that the js-options fixes the Object.assign issue. The broken Symbol.for polyfill though seems to linger on, probably need to wait for a Google Closure compiler bump for this? Seems the issue is fixed upstream (or at least closed).

what issue is that?

https://github.com/facebook/react/issues/13414 , traced to https://github.com/google/closure-compiler/issues/3052

yes I saw that. how to do I reproduce that though?

I'm in the process of bumping the closure compiler anyways so it may just work

still need a way to reproduce that to test

My minimal repro example shows that

Correct rendering

(building… 😄 )

IE11 with broken Symbol polyfill rendering

ah ok

For some reason, it’s 60107 wherever a react fragment appears. I haven’t been able to get any meaningful google hits for this so potentially you’ll get another number.

didn't notice that 😛

Do I have to go to ES3 or should just rewrite polyfills do it?

the symbol issue also doesn't work with the latest closure compiler version

hmm but it looks like thats not a react issue

if I do this the fragment renders correctly (just removed hx)

(defn ^:dev/after-load render []
  (react-dom/render
    (r/createElement r/Fragment nil
      (r/createElement "div" nil "content 1")
      (r/createElement "div" nil "content 2"))
   (js/document.getElementById "main")))

Could be on subsequent renders?

Probably not, hx should only render once.

In any case, I’ll shrug this. Could be nice to have a self-contained bundle with all the necessary polyfills, but probably best to just load them in HTML.

Sorry for taking up your time

Might be something wrong with hx. Feel free to file an issue