I don’t think that’s true anymore but you should double check

I’m also curious whether the flattening thing helps here

anyways try it out and report back

I'm seeing 'dirname is not defined' with fw on nodejs. The only thing I can think of is that dirname is context sensitive (I think?) and fw's client breaks the context. anyways, reverting the bootstrap node changes in 59a7f26 fixes

@pat sounds like something to report to figwheel and then see if it can’t be sorted there first

@dnolen might be the same issue as require

I think __dirname and __filename may need to be bound to global

oh right writing it to global

@anmonteiro I don’t know about filename since that needs to be done by require

hrm, but I guess we should bind it at root, and expect require to do the right thing later

I'm referring to this comment: https://github.com/nodejs/node-v0.x-archive/issues/9211#issuecomment-134412415

yeah

cool, happy to take a patch for that

@dnolen I'll have something for you tonight

k cool

@dnolen A typo in externs guide: Cannot infer target type in expression (.bar x) ... -- the code above calls (.baz x).

@dottedmag you can edit that page here: https://github.com/clojure/clojurescript-site/blob/master/content/guides/externs.adoc

@anmonteiro hey 🙂 did you try running this: https://github.com/swannodette/es6-demo/compare/closure-master?

I haven't, not yet

having trouble?

@anmonteiro an idea by any chance how that deps.cljs has been generated?

I’m currently looking into how cljsjs could utilize the new stuff. Your changes to Om seem like it would be relatively straightforward, the es6-demo however seems very different (i.e. all files are provided as foreign lib individually)

if I had to guess, I'd say it's these new functions: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/build/api.clj#L222-L292

@martinklepsch ^

going to bed now, curious to see what you come up with. Hope the above helps

Well, don’t expect too much haha 😄

Good night 🙂

Thanks for the pointer

doh, just node test.js 😉

@martinklepsch thanks

got React production build working with env variable set via

(ns process.env)

(goog-define NODE_ENV “development")

:closure-defines {'process.env/NODE_ENV "production"}

React + ReactDOM no env var 71KB gzipped env set to “development” 69KB gzipped env set to “production” 52KB gzipped

it’s funny that development build with env var set has less code that the one without 😄

however, Webpack production build is 42KB gzipped

@dnolen trying the latest cljs with shadow-build, I get literally thousands of infer warnings although I did not enable it anywhere WARNING: Cannot infer target type in expression (. cljs.core/PersistentVector -EMPTY-NODE) ...

is this intented to be always running?

probably missing some setup in shadow-build but I'm confused why this code is reached at all

@dnolen not shadow-build related, if you actually enable :infer-warnings globally you get many many warnings everywhere

https://github.com/thheller/cljs-infer

would produce warnings for cljs.core as well but it is using the cached version so it is hidden

so the warning is always generated, it is just silenced when *warn-on-infer* is not set

that doesn't seem right to me

looks like only a tiny figwheel tweak to get file reloading on dir based foreign libs

Right now I'm adding foreign libs to the watched paths by default, hasn't been a problem so far. But I'm think I'm going to need to make this explicit instead of implicit.

@roman01la ROCK

hilarious that’s so easy 🙂

@thheller :infer-warnings is not intended to ever be set

@roman01la can you share your project maybe?

it’s useless when applied globally, the guide says this

@martinklepsch I would just refer to the guide now, it covers everything from es6-demo but with like - documentation

happy to answer any questions that you may have about how it works

@dnolen good morning 🙂

basically we shell out to node to run module-deps on a your specified CommonJS entry point

that returns a JSON value of the dependencies, an array

the interesting part about the es6-demo was how it integrated React or “npm library code” more generally

@dnolen that is not what I meant. I meant that there is no way to actually toggle :infer-externs as off, the work is always done.

we just map over it grabbing ”file”

which I disagree with as a concept

@thheller right we do the work anyway - not a big deal, but easy to fix in a patch

@martinklepsch but the JS guide covers that as the last thing - I don’t know what you mean

@bhauman cool 🙂

@dottedmag thanks fixed

I did update the deps.json by running node test.js > deps.json but got stuck after a while with this one:

ERROR: JSC_COMMONJS_MODULE_LOAD_ERROR. Failed to load module "react" at /Users/martin/code/es6-demo/src/libs/NodeStuff.js line 2 : 12
Exception in thread "main" java.lang.IllegalStateException: Cannot build without root node being specified

My motivation of using es6-demo was to have something working and tinker with that as foundation

@martinklepsch I keep saying that the guide shows you how to do all this 🙂

I don’t know why you are struggling with the es6-demo 🙂

@martinklepsch which part “might not be possible"

are you referring to in the guide?

@dnolen old foreign libs behavior like:

the reason you’re failing at that spot is that module-deps doesn’t add package.json entries

I got it working by manually add the one for React

the guide one just works

because in cljs.build.api we add the package.json entries after calling module-deps

That ^ should work right?

shoot skip the :as React

@dnolen ^

maybe but it’s hard to say I think using es6-demo here is very counterproductive for everyone 🙂

I think it would be cool to have it working so it can serve as a playground for people interested in messing around with the module stuff

I'm pretty sure that what I'm doing should work

@martinklepsch right, but I don’t know why you can’t do that with the final example in the guide is all I’m saying

> the reason you’re failing at that spot is that module-deps doesn’t add package.json entries you mean as in it fails because react isn’t in package.json? (it is so I guess I’m misunderstanding)

es6-demo was a hack and I didn’t document all the details that I fixed in ClojureScript itself

everything I learned was put into ClojureScript directly and automated

@martinklepsch so let’s rewind and let me explain how it works

Google Closure has Node.js resolution for CommonJS inputs

by resolution I don’t mean finding files

In es6-demo could I require react from core.cljs? I think this is where my misunderstanding might stem from

@martinklepsch only if you supply a :provides

right, ok. I think I’m slowly catching up 🙂

so Google Closure expects to see all of your inputs

the problem is we don’t know what they are!

we need some other tool to figure out what the CommonJS deps are

module-deps does this

so ClojureScript shells out to get the CommonJS deps so we can give the Closure Compiler all the inputs

but it needs to do more, it needs also to include package.json entries

@dnolen what I'm seeing it that :provides [React] is not putting an entry in cljs-deps.js

anymore

because those tell us what main: is

ok, 1s here. What needs to include package.json entries? and what is main: in that context? is that a node/npm thing?

@martinklepsch Node.js dep resolution

https://nodejs.org/api/modules.html#modules_all_together

ok, so that’s what goes into require() essentially

in order find the entry point you may need to look at package.json

I’m not talking about top level package.json

I mean node_modules/react/package.json

which says main is node_modules/react/react.js (not index.js the default)

oh, ok, that clears up the confusion about that part

@bhauman that’s not how :provides ever worked in Maria’s code

ok I'm getting there

so another explanation which might clarify things

yep just figured that out

ok cool

sorry for noise

no problem 🙂

I’m enjoying the enthusiasm that people have for figuring how this stuff works 🙂

@martinklepsch https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/build/api.clj#L298

this is exactly what's missing in es6-demo

that’s why you can’t load React

@dnolen yup, the pieces start to fit a bit more. I think you gave me enough to chew on for now. Thanks for taking the time to explain! I’m sure I’ll be back though 🙂

cool

@dnolen OK I see the problem I'm having

I think I have a better question

go for it

actually I think I may have answered it for myself

but...

the react in es6 demo

actually let me explore more

k

@dnolen ok I got it

it seems the example above

the common js example

is compiling a no op

goog.provide("module$resources$js$react");var module$resources$js$react={};
(function(f){var module$resources$js$react=f()})(function(){var define,module,exports;re

note the var assignment

“is compiling a no op”?

see the var assignment in the function

the react module is never required

or never put into the global env

I don’t know what you mean

oh darn this is hard to exxpresss

the code there is just Google Closure rewriting that CommonJS module into a Google Closure namespace

we’re not involved in that

so my snippet before no longer works

ok

so what I'm saying is that :provides used to reify module$resources$js$react into the global env

somehow

and no longer does

hrm I don’t see how

var module$resources$js$react={};

is exactly that

OK I'll look further

if not handled directly by goog.provide

@bhauman but let me see if I can see what you’re seeing

are you using the latest React that you downloaded or something?

I'm using the older version of es6-demo

the react there

and I'm using the :provides the old way

you may want to let me confirm that this behavior changed first

@dnolen yes the behavior changed

in cljs 1.9.303

the top level var get's assigned when :provides is used the old way

actually 1.9.293 behaves this way as well

@bhauman right but we can’t do anything about that

that’s just Google Closure stuff

and you don’t need the var

goog.provide creates it

Google Closure CommonJS compilation changed here - nothing in ClojureScript

well I can't require it or reference it

it's hermetically sealed

right this is something we discussed a long time ago but maybe it wasn’t clear then

we don’t know what the name is going to be

Maria does preserve that original provides information in the compiler as an alias

so we can map from Closure’s generated name to the one specified by the user

OK I'm getting there

it is a novel behavior change in the relationship between require/:provides in foreign libs for common js

@bhauman it’s been like this since Maria implemented it 1 1/2 years ago 🙂

no

nothing has changed

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1958-L1961

then we aren't communicating verywell

even if the change is on closure proper

its a novel change

I think you are still confused here

I used to be able to require and refer to the provided name

goog.provide always create the top level object

someone at Google wrote a commonJS thing that generated a top level var

and it would have React in it

someone realized it was redundant, and removed that

none of this matters at all

Maria’s patch realized that module names are generated

it was always this way

so she preserves the foreign lib :provides and maps to the generated one

nothing has changed here still

this is all new stuff

what you’re talking about is normal foreign libs

yes

so there are no changes here

same stuff as it was the whole time

@bhauman so the problem you have now is how to require a thing at runtime

for this new kind of compiled thing

fortunately I think this is completely solveable

we generate cljs_deps.js

a file can have multiple provides

we just need to dump the original alias

@bhauman do you agree that’s all you really need?

yes, I think, a way to require the :commonjs module

but I'm not super frustrated with this

I don't use common js modules

right there are harder problems to sort out here that we haven’t even gotten to yet as well

(ns foo.core (:require [object-assign]))

I think I just got hung up on some transient behavior in 1.9.303

doesn’t work

@bhauman right, I think for Figwheel you just need the original aliases in the goog.addDependency(… calls

I'm not even there yet

figwheel should work just fine with all this

it uses the generated aliases

hrm ok then I don’t think we need to do anything at all then right?

require etc. already works

just trying to figure if you actually need something 🙂

I'm at a cafe, if I go someplace where we can chat, do you have a minute?

oh wait ... I think I got this

@bhauman happy to chat if it makes it easier

cool 🙂

yeah just ping me on skype if you want

right so I'm going to get off of this common js stuff for the moment and just get things in figwheel working for dir based foreign libs

WOW

React + ReactDOM Server with advanced compilation 32 K 🙂

21K smaller than what FB provides

@roman01la ^

woot!

@roman01la the reason you weren’t seeing this result is because of :target :nodejs

and don’t use println

then you’ll see Google DCE really kick in

@dnolen: what does it mean "what FB provides"

just production scripts

react + react dom server

Ah, ok. The stats I reported was for React + React DOM browser, want using Node as a target or println

*wasn't

There was also a diff between Webpack and cljs build in 10 kb, I think that's because of runtime overhead, but @martinklepsch pointed out that cljs runtime should be elided, so I'm not entirely sure if Closure Compiler can optimize React as JS optimizer, but that doesn't make sense to me

the numbers I reported show that Closure can optimize React

https://twitter.com/sebmarkbage/status/825385505009250304

it also appears FB is coming to same conclusion

I've used Webpack 2, not sure how Facebook do it

So there might be a runtime or Webpack 2 can elide more stuff

Not sure how to compare both builds properly to find out

@roman01la: I thought they used browserify

Should be in the React repo somewhere

to me the coolest thing is that stuff like this is so easy to try/test now 🙂

such a massive pain before

Not sure how worthy the comparison between webpack/browserify is though....

@anmonteiro: I mean Webpack vs Closure

I was answering to "not sure how FB do it"

Yeah, things are much better now. @dnolen are there any ideas on how to make it possible to consume NPM deps directly, without JS entry point?

@roman01la task in JIRA about that

Probably a lookup for every package json

will require hammock time

Ok, will check it, thanks.

http://dev.clojure.org/jira/browse/CLJS-1914

based on what Chad Killingsworth said this may be easier than it sounds, dependency mode STRICT implies all of the machinery is already present

I was wrong! And I’m glad I was 😄 React + ReactDOM 32KB vs Webpack 42KB

probably cljs build caches was the cause

@dnolen: that JIRA ticket above... by "directly requiring" you mean without needing to add a :provides entry?

ok I've got hot reloading working when foreign lib :file is a dir

wow its really working well

So what's the best way most common way for me to require React in my :es6 hello world

?

@bhauman I’ve just published a test repo, you can see how it’s done there https://github.com/roman01la/cljs-npm-test

You may have noticed that our ES6 file does not declare its dependency on React, ReactDOM, or ReactDOMServer via import. Handling this correctly depends on a pending patch to Google Closure to support Node.js module resolution for ES6 source files. When this change lands this guide will updated.

@roman01la that’s what I was saying 🙂 but glad you could repro

@anmonteiro I mean treating CommonJS modules as Google Closure namespaces

right now you have to go through a CommonJS entry point

@bhauman yeah waiting on Closure Compiler here

Ah gotcha

@dnolen and I can't require react via the commonjs module like you did in the es6-demo either

@bhauman I don’t know what you mean

let's skype!

haha can’t now

oh bummer 😞

making breakfast

cool Imma get lunch

boom https://github.com/google/closure-compiler/commit/35e1e1b102eea96f8a3aa23adf1763a1e6f9acbe

bummer we'll have to wait ~1 month for a release

that commit missed the Jan release by 3 days

@anmonteiro it’s February in a couple of days 🙂

and it sounds like we’ll need to cut a new release soon anyhow

right, but we need to wait until the end of February 🙂

@dnolen just attached the __dirname patch to http://dev.clojure.org/jira/browse/CLJS-1916

Thanks!

@anmonteiro sweet

@anmonteiro applied

@bhauman did you sort out your issue?

maybe we could chat for a sec?

@dnolen ^

sure

do you have screenhero?

I don’t just Skype

cool

@dnolen weird edge case that works in Clojure but not CLJS:

cljs.user=> (def foo '(:a :b))
#'cljs.user/foo
cljs.user=> (case foo '(:a :b) :works)
Error: No matching clause: (:a :b)

found it because inadvertently quoted the list passed to case when I really wanted a non-quoted list

File a bug thanks

I don't think that should work in Clojure

Lists in case represent a list of cases, not sure if you're aware of that

You can't match a literal list in case afaik

@alexmiller I'm aware of that, but my example above seems to work in Clojure

it works as if matching a literal vector

my understanding is that ClojureScript should also mimic that behavior

I'm saying I think maybe Clojure is wrong here

oh hrm

I would need to do some more poking to be more sure

right. so maybe needs some more analysis from your part before we reach any conclusions

@alexmiller in any case this is open for reference http://dev.clojure.org/jira/browse/CLJS-1917