Clojurians
#cljs-dev
<
2019-01-12
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

thosmos16:01:51

I'm hitting an error in attempting to compile a hello-world browser app that does (ns (:require [firebase])) with :npm-deps {:firebase "5.7.3"} :optimizations :simple :language-in :es6:

SEVERE: /Users/thomas/Develop/cljs/cljs-node-example/out/node_modules/@firebase/webchannel-wrapper/dist/index.esm.js:4: ERROR - Module scoped variables named 'goog' must come from importing Closure Library's goog.js file..
var commonjsGlobal=typeof window!=="undefined"?window:typeof global!=="undefined"?global:typeof self!=="undefined"?self:{};var e;var goog=goog||{};var h=commonjsGlobal;function l(a){return"string"==typeof a}function m(a,b){a=a.split(".");b=b||h;for(var c=0;c<a.length;c++)if(b=b[a[c]],null==b)return null;return b}function aa(){}function ba(a){var b=typeof a;if("object"==b)if(a){if(a instanceof Array)return"array";if(a instanceof Object)return b;var c=Object.prototype.toString.call(a);if("[object Window]"==
It appears that this is related to an open Closure issue https://github.com/google/closure-compiler/issues/2644, which dnolen has already commented on. It's unclear to me whether this is fixed or not, or if there's a work around?

thosmos16:01:17

If I understand it correctly, which would be barely if that, the wiki mentioned in that issue suggests that the following might work:

// CommonJS import of ES6 module
var Foo = require('/path/to/es6/module/foo').default;
Is this relevant to my error?

thheller16:01:34

@thosmos no. :npm-deps just can't process the firebase stuff on npm since it is a compiled version of closure code

thheller16:01:46

that confuses the compiler as it thinks it is getting uncompiled code

thheller16:01:04

firebase probably just isn't compatible with npm-deps

thosmos16:01:12

Is this a CLJS compiler issue? In other words, do I understand correctly that if the CLJS compiler knew that it was compiled closure code, that it could just load it, or create a load function for it, rather than attempting to recompile it?

thheller16:01:22

probably not no. its a bit more complicated than that :wink:

thosmos17:01:12

oh I think I'm beginning to see, it's because it's already been compiled with advanced compilation, whereas npm-deps is attempting to load uncompiled modules in order to compile them into the same build, do DCE, etc?

thheller17:01:20

npm-deps will attempt to read the JS files and convert them into a format it can read

thheller17:01:44

it looks like it finds a goog reference which is "reserved" for the closure library

thosmos17:01:41

thanks for the tips, I'll keep reading and will hopefully understand it better soon

thheller17:01:13

Honestly don't waste your time with :npm-deps, it is too unreliable at this point. Use the recommended webpack approach or shadow-cljs and save your sanity :wink:

richiardiandrea17:01:46

Agree w/ the the above, I use npm-deps only with cljs-test-runner and there are all sort of quirks

thosmos17:01:41

Well, maybe once I understand it better I'll be able to offer some help in making it better

thosmos21:01:50

@richiardiandrea are the quirks documented somewhere that I can see?

richiardiandrea22:01:26

Well I don't know, maybe Jiras? the symptoms usually though are that the compiler cannot find a namespace associated with the XYZ npm package

thheller23:01:18

FWIW I think most of the issues are actually Closure Compiler issues. There isn't much you can control from the CLJ(S) side in this regard.

richiardiandrea23:01:57

I am not entirely expert in this but the problem I am specifically talking about is that sometimes Cljs cannot "discover" npm packages easily - I guess show has this covered because of the different way it analyzer npm packages...I remember a Thomas blog post on this