fixed https://dev.clojure.org/jira/browse/CLJS-2327

cc @mhuebert if you wanna try it locally

also fixed https://dev.clojure.org/jira/browse/CLJS-2326 just now. @dnolen one of these will probably need a rebase once you apply the first one

let me know if and which one

@anmonteiro appears to be working! able to refer react/react-dom, and also this is the first time I’ve got a :modules build working (previously had some issues with some transitive js-deps which have been sorted out in your recent work)

it’s also working for me here

Alex Miller’s clj stuff is really quite nice, I’m thinking we should switch our primary docs to it when it’s properly released

we don’t have to talk about rlwrap anymore, and it’s way simpler to cover deps than project.clj or Maven

It makes you wonder if it could lead to an alternative to the cljs.jar approach

yes IMO it really solves that problem

(Meaning, cljs.jar seems to bundle a lot of deps on the user’s behalf)

clj would be an acceptable way to submit minimal repros

Longer term, I wonder if some of the same magic that clj uses to search for the “latest” release could somehow lead to something similar that searches for the latest ClojureScript release. (It’s perhaps way to early to get a feel for what something like that might mean.) But, yeah, just using clj as it is meant to be used seems like a good idea.

@anmonteiro Do you have any tips on getting IntelliJ to detect Closure-compiler properly? Looks like it only supports pom.xml file and I think Closure has proper configuration on pom-main.xml file

is the clj stuff online somewhere? nvrmind: found the thread https://groups.google.com/forum/#!topic/clojure/FpMqtNu0TCE

I’m compiling using :optimizations :simple for the first time now with the latest cljs, and I am getting a runtime error that I haven’t seen before: Uncaught TypeError: Cannot read property 'env' of undefined. There is just the one file in the stacktrace (the :simple-compiled file). The error comes from fbjs in node_modules, trying to read process.env: var module$Users$MattPro$Documents$sites2017$maria$node_modules$fbjs$lib$emptyObject={};"production"!==process.env.NODE_ENV&&Object.freeze(module$Users$MattPro$Documents$sites2017$maria$node_modules$fbjs$lib$emptyObject);function makeEmptyFunction...

I can avoid the error by running <script type="text/javascript">window.process = {env: {}}</script> first

@mhuebert I suspect this might be a dep sorting issue due to :preloads

turn off optimization set :debug-inputs true and paste the dumped inputs somewhere

in the meantime your workaround is probably the right way to go

@mhuebert try master

@tony.kay when you get a chance could you try master as well - I tweaked how we handle :preloads, in your case I want to make sure your :modules stuff is still working wrt. dep order when applying optimization settings

I have noticed this little quirk while trying the string require, which is a bit odd (at the REPL):

(require '"something") ;; there is a quote before the apices

minor ticket is fine

kk

@juhoteperi sorry I dont use intellij

ah ok

@juhoteperi IntelliJ processes all the poms

they become different Maven profiles in the project

Oh, I updated IntelliJ and now I can see the profiles

I have a question, with the advent of the new string require, is there a more concise way to require https://google.github.io/closure-library/api/goog.string.format.html ?

sorry maybe I am off-topic here actually

@richiardiandrea no. different concerns

@dnolen FYI looks like my PR to Closure might land today https://github.com/google/closure-compiler/pull/2620

nice!

I didn’t try material after putting it together though

@dnolen if you’re still around, another enhancement patch: https://dev.clojure.org/jira/browse/CLJS-2330

@anmonteiro testing

@juhoteperi we could maybe use global exports in node_modules case to fix old style usage

@dnolen this is only for compatibility & consistency with a case that we don’t really expose, but advanced users can poke at

since global exports tells us the globals, we could rewrite those references

(I’m speaking about CLJS-2330)

because processing node_modules under :target :nodejs doesn’t really work with :none, but you can use that with :simple

if you’re really determined

@anmonteiro got it

@dnolen Hmm, interesting. Even (def a js/React) (.createElement a ...) should probably work as a would point to module$foo$bar$react or something, and Closure should take care of renaming the calls?

@juhoteperi what I’m suggesting is this

if we have global exports defined they are applied universally

js/React can never be js/React

it will always get rewritten to a generated alias

so

(:require [cljsjs.react]) becomes (:require [cljsjs.react :as module$React])

then (def a js/React.Component) -> (def a module$React/Component)

this would should fix all old style usage as long as people aren’t doing crazy dynamic stuff - in which case don’t really care

What do you mean with crazy dynamic stuff?

Something like (def react (cond (exists js/React) js/React ...))

no, I mean stuff like (goog.object/get js/window "React")

Okay, I think no major libs do that

Anyway, I already updated to om/rum/devcards/sablono to use new require, but couldn't get tests passing with simple changes. I'll put up PR on each project for commenting and testing.

k

https://dev.clojure.org/jira/browse/CLJS-2331

And I'll link to that

cool, thanks

I think most of the problems with the changes are from code generated from macros that tries to call react/

E.g. (.apply react/Component this# (js-arguments)) at om.next defui*

Causes Uncaught TypeError: Cannot read property 'Component' of undefined

hrm ok, I’ll have to look at that later

https://github.com/r0man/sablono/pull/175 https://github.com/tonsky/rum/pull/148 https://github.com/omcljs/om/pull/887 https://github.com/bhauman/devcards/pull/127

There is also lots of warnings from namespaces that use defui about missing react namespace

Those namespaces don't use react/ directly so they don't have require

right

@juhoteperi I've been reading the comments and trying to understand the need for this change, and to know how backwards compatible it is

It will allow users to use the library with both foreign-libs and node modules. Which is not really possible (currently) if library accessess js/React or other globals.

@bhauman short summary - it doesn’t really affect current usage

however making old stuff and new stuff work at the same time will require a bit more work

gotcha

thanks guys

the important thing to understand is that :global-exports doesn’t break js/Foo

it just allows you to use foreign libs like normal requires

CLJS-2331 would go the extra mile

it would convert all old style foreign libs usage to become new style foreign lib usage

@dnolen Yeah, but it’ll be tomorrow. Busy today.

@tony.kay no problem

Very very cool stuff, best of all worlds. Thats the way I like my cake.

it’s in Closure master :tada: https://github.com/google/closure-compiler/commit/e6e4313941289d17b135901145fd1be90735ccf9

@anmonteiro nice!