Fork me on GitHub

Here is another example utilizing synthetic index.html generation via cljs.main

Oliver George02:02:23

I'm trying to do a goog.require from a JS file and it causes a "Namespace never provided" error when I do an optimised build.

Oliver George02:02:29

Same is fine from a CLJS file.

Oliver George02:02:54

e.g. (ns a.example1 (:require cljsjs.leaflet)) in a/example1.cljs vs goog.provide('a.example2'); goog.require('cljsjs.leaflet'); in a/example2.js

Oliver George02:02:58

Seems like a bug.


not a bug, but it’s easy to be confused about how foreign libs actually work


but no you cannot call goog.require to load foreign libs from JS libraries and expect it to work, because foreign libs are not real Closure namespaces

Oliver George02:02:31

Thanks David. I expected that from a foreign lib. My confusion was expecting a JS file in the source path to be treated like google closure compatible js.


@olivergeorge the problem is that since foreign libs aren’t real Closure you libs you cannot goog.require to load them


the fact that we happen to do this very cleverly in the compiler is very much an implementation detail

Oliver George02:02:09

Thanks for that @dnolen. I did a few experiments based on that. Problem only exists when my Google Closure Compiler Compatible Code requires the CLJSJS bundled Foriegn JavaScript Code (as you describe).

Oliver George02:02:09

Curious workaround is that my JS lib can require a CLJS ns which does the CLJSJS require.

Oliver George02:02:42

(for anyone reading along this cljs reference on dependencies helps clarify


How should I interpret #'foo/bar


It evaluates to the current var content, do you have a more specific example that needs clarification?


@savaki it’s a var that references foo/bar (which is bar in the resolved foo namespace)


so if foo/bar was a function, the difference between calling (foo/bar :foo) and (#'foo/bar :foo) would be that the latter is only a sort of ‘pointer’ to a symbol, and the former being the actual symbol


Hi. I’m trying to include apollo-utilities (a JS library) into a browser-targeting CLJS project with :npm-deps. It builds fine but the generated/transformed out/node_modules/apollo-utilities directory still contains ES6 and fails loading in the browser. I can see where this is coming from (`"module"` in package.json of apollo-utilities points to an ES6 file). But I don’t understand the :npm-deps process well enough yet to tell whether this is expected or whether I’m missing something to make this work. Any ideas?


I just ran into an unusual issue, probably due to my lack of understanding. I’m trying to show a FontAwesome icon and toggle it when it is clicked.


I found that the SVG icon does not work, but the old style ‘web font’ does.


Could this be due to some magic that FontAwesome performs to load and display SVG icons?


I should add this is a Reagent component.


Hi, I'm writing a cljs library, if I'm using clojure.core.async "0.4.474", and the library user is using clojure.core.async "0.4.475", how can I determine if an object is an instance of core.async/chan?


This is a public service announcement: everyone should be using cljs-devtools. (I am not affiliated) To me, it is as important as figwheel to a quality dev workflow, perhaps more important. The other day it shocked me to discover a team who were unaware of it. That's a big hole in community communication that we should fill (I'm not sure how, other than this)