Fork me on GitHub
#clojurescript
<
2020-09-15
>
Elso09:09:30

I've got this recurring problem where every few days my app breaks on calls into a node module with TypeError: $jscomp.inherits is not a function and up until now I could always resolve it by bumping either CLJS versions or those of the node module, but now both are up to date and a few days in the error reappeared and I don't know what to do about it. This link https://github.com/google/closure-compiler/issues/2398 suggests the issue is somehow with the closure compiler - can anyone maybe shed some more light on this?

‚úÖ 3
thheller09:09:57

@d.eltzner012 its a polyfill issue. what is your setup? I'm presuming shadow-cljs? which :target? which version?

Elso09:09:08

yes - :target is :browser and version was 2.11.1, but I'm currently rerunning it with 2.11.4 to see if that suffices

thheller09:09:12

if you want to get rid of it completely you can just set :compiler-options {:output-feature-set :es6} (or :es7, :es8). depending on which older browsers you want to support

Elso09:09:34

Okay, first version bumping shadow 'solved' it again, so thanks. Second, and sorry for my ignorance here, but I don't really see the connection - so I guess by default the output feature-set is by default set to something lower than es5 and that tends to be problematic somehow?

thheller09:09:37

the default is :es5 which means if there are npm packages that contain newer language features they are compiled down and polyfills are added

thheller09:09:53

$jscomp is those polyfills but sometimes they don't get added correctly for some reason

thheller09:09:33

$jscomp.inherits is used for class Foo extends Bar polyfilling I believe

thheller09:09:06

so :es6 might be fine and that works in 98% of all browsers anyways

Elso09:09:29

I guess I'll go with es6 then. thanks again!

Elso09:09:44

for your awesome stuff in general too obviously.

thheller09:09:55

this might just be a bad cache for some reason. if it gets into that state again you can try deleting .shadow-cljs/builds/your-build and restarting the watch

ūüĎć 3
thheller09:09:49

would help to have a reproducible case. I've been trying to fix this for a while now but can't quite figure out how it gets into a bad state ūüėě

Elso09:09:29

I'd love to help but I obviously don't understand the circumstances either - I'm also quite the noob in JS-land so too much confusion here

Mitch22:09:07

Regarding the `infer-externs` compiler option: Are you intended to move the generated externs in `inferred_externs.js` to a file that you use for advanced compile? Or is it supposed to be enough to use type hinting and `infer-externs` when you use advanced compile?

Mitch00:09:48

I think I found the answer https://gist.github.com/swannodette/4fc9ccc13f62c66456daf19c47692799:

Simply add a new compiler option :infer-externs true to your compiler config. Now when you build your project you will get a new file in your :output-dir named inferred_externs.js. When you do an advanced build, this externs file will be used.
So, your `inferred_externs` should be in the `:output-dir` of your advanced build. Therefore, you might need to check it in to source control if your build is performed by an agent