I've run into a snag with commonjs modules in the latest clojurescript, but I would like to check about what the intended behavior is

Basically I can (:require [prefix.namespace :as myns :refer [myfn]]), and then I can use myns/myfn or myfn in my code without any issues.

However, if I try using prefix.namespace/myfn in my code, I get a compiler warning about the namespace prefix.namespace not existing and a console error that prefix is not defined.

In the javascript output, references to myns/myfn or myfn expand to module$prefix$namespace.render, wheras prefix.namespace/myfn expands to prefix.namespace.myfn

Is it feasible (and/or desirable) for the clojurescript compiler to resolve all of these correctly?

@chris-andrews sounds like this is your issue, right? http://dev.clojure.org/jira/browse/CLJS-1820

@anmonteiro oh wow, yes, that’s it exactly

it’s in the works 🙂

That’s awesome

so I’ve been playing with commonjs bundles a lot lately, and the current state is really pretty fantastic

I suspect that advanced optimizations will break everything, but it’s making it very easy to use npm/bower code

I think I’ve also figured out how handle dependencies that are shared between bundled commonjs and clojurescript (namely react)

@chris-andrews that’s interesting news

@dnolen I’m happy to try to document some of how this works if anyone is interested in it

@chris-andrews a blog post on what you’re doing would be interesting

knowing whether libraries are or aren’t advanced compilation safe is useful - that’s the big limitation here

we could do a lot for extern inference for CLJS -> JS interop

but JS -> JS seems like a lost cause

@chris-andrews Does it really work with npm modules? As far as I know, Closure can't yet handle npm require

@juhoteperi there’s support for CommonJS and AMD I thought

https://github.com/google/closure-compiler/issues/1773

@juhoteperi The latest clojurescript is working with npm modules for me with the caveat that you have to bundle your javascript first

Right, so I want to be able to use them without bundling

Yeah the problem is that require(‘package’) in node has that weird method of searching for what you required

ah right k

Currently Closure has hardcoded search logic for require

We can either wait for them to fix that, or propose a fix for them

Or, if we preprocess the packages anyway to generate deps.cljs, we could rewrite requires so that Closure can deal with them

Yeah I’ve been pretty ok with the current constraints, basically I require whatever I want and break that out into modules and just webpack them in my build process

@chris-andrews yeah some kind of write up about what works well and a description of the limitations you’ve run into would be definitely be useful

@dnolen I’ll definitely put something together and ping you when it’s available

I do think that using webpack means there won’t be any dead code elimination from anything you run through it (although I think that could change in some cases with webpack 2)

@chris-andrews right thought I don’t see how Webpack can do any better than Google Closure here at all

at best you might get module level elimination - but that’s just implicit in how Google Closure works anyway

I’ve listening to people talk about getting DCE in these JS tools for years

“We’ll beat Closure"

time passes ...

Here is my work on automatically packaging npm modules as jars: https://github.com/cljsjs/cljsjs.npm

nothing

@dnolen yeah I don’t think commonjs in general can be optimized as well as google closure compatible code

I’m mainly doing this for the cases where you just want to use something that isn’t available through cljsjs with very little friction

@chris-andrews I’m assuming the main benefit here is normal looking :require for you then?

I bundled a file that just contained module.exports = require("d3");

and then could do:

(:require [js.d3 :as d3]) (-> (d3/select "body") (.append "span") (.text "hello world"))

right

@dnolen so I just tried my d3 hello world and it does compile with :optimizations :advanced

@chris-andrews is that because you have externs? (also d3 may be Closure compatible by avoiding JS string property metaprogramming)

no, I have no externs

some sample code:

}([function(a, c, d) {
  a.h = d(1);
}, function(a) {
  a.h = {s:1, u:2};
}]), G = F.s, H = F.u;
function I() {
  console.log("hello commonjs");
}
;I.v ? I.v() : I.call(null);
d3.select("body").append("span").text("Hello, npm!");
console.log(function(a) {
  return a * a * a;
});
console.log(G);
console.log(H);
console.log(G);

so it looks like it may have inferred externs for d3?

however, it did not optimize any of the d3 source code

actually, I think it did optimize some of the d3 source

if it didn’t that would be very surprising

(a bug)

in the ClojureScript JS module processing support

well a lot of it appears verbatim, including comments

I thought it might not optimize umd bundled code because it’s wrapped in a big function call that gets evaluated

big function call shouldn’t matter

Closure optimizes inside of closures

if white space isn’t collapsed and comments aren’t present then advanced optimization might not have been applied

then looks like maybe a bug

I’ll see if I can put together a collection of testing out different things with this