Fork me on GitHub
#clojurescript
<
2017-07-28
>
anmonteiro00:07:01

@jeremys figured out your problem

anmonteiro00:07:49

but we assume every NPM dep is commonJS

anmonteiro00:07:14

so we’re not converting it and can’t extract the correct provides

lwhorton00:07:08

does the compiler provide a way to prevent the renaming of particular namespaces? if I wanted to expose my-ns.core to the outside world even under :advanced compilation, how would I do that? an externs file doesn’t seem to affect the output namespaces (wouldn’t expect it to, I dont think)

anmonteiro00:07:17

@lwhorton

(defn ^:export x ...)

lwhorton00:07:27

so that will preserve “my-namespace.x” such that I can call window.my_namespace.x instead of just preserving x but clobbering my-namespace into something like window.ab.x = ...?

anmonteiro01:07:26

@jeaye doesn’t obviate the need for externs if that’s what you’re asking

jeaye01:07:44

It is, thank you.

anmonteiro01:07:56

the advantage of having CLJSJS though

jeaye01:07:07

CLJSJS doesn't contain a single react-native package. 😞

anmonteiro01:07:08

it that you can have those in the classpath without actually requiring the namespaces

anmonteiro01:07:20

and CLJS will crawl the classpath for externs

jeaye01:07:42

That's handy though.

anmonteiro01:07:44

I think @mfikes was working on RN externs

jeaye01:07:56

For RN specifically, but not any RN packages.

jeaye01:07:40

Does that site work for you, @anmonteiro?

anmonteiro01:07:05

what problem are you having?

jeaye01:07:29

Hitting "Load" shows a spinner on the right for a second and then nothing.

jeaye01:07:03

Also tried on Chromium, with the same results.

jeaye01:07:27

Oh, I bet it wants the raw. derp

jeaye01:07:51

Actually, that doesn't work either. Same behavior.

anmonteiro01:07:22

probably doesn’t work with ES6? let me try

anmonteiro01:07:00

@jeaye raw github link also gives me this error in the console:

Refused to execute script from '' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.

anmonteiro01:07:37

it probably wants bundles as well

anmonteiro01:07:55

won’t be able to eval const Auth0 = require('react-native-auth0'); if you only pass it that file

anmonteiro01:07:01

which may be hard for React Native stuff

jeaye01:07:04

I don't see how this would quite work for react native then.

jeaye01:07:38

So, using RN and I've installed a dozen RN packages through NPM. What would be the best way of getting externs for them?

jeaye01:07:34

As you can imagine, my app is entirely unusable with :advanced optimizations.

jeaye01:07:28

@anmonteiro So, assuming I can generate some externs, then, using your latest changes, I should not use js/require, but instead :require to bring them in (directly from node_modules), add the externs to :foreign-libs, and I should be all set?

jeaye01:07:55

In that case, is there really any benefit to :require over js/require?

anmonteiro02:07:53

using module/function instead of (.function module)

jeaye02:07:41

Furthermore, does that new change allowing :require obviate the need for one to specify the {:file "foo.js" :provides "foo"} in :foreign-libs?

anmonteiro02:07:07

yes, if foo is in node_modules

jeaye02:07:08

So, with js/require, even if foo is in node_modules, I'll need to use {:file ...} in :foreign-libs as well as put the relevant data in :externs. With :require, I need only do the externs.

anmonteiro02:07:50

with js/require you don’t need foreign libs entries

anmonteiro02:07:36

under :target :nodejs (or any other environment that has native require) it’ll just emit require calls that are resolved at bundling-/runtime

jeaye02:07:07

I'm targeting react native, but I do have js/require (and I am currently using it everywhere).

anmonteiro02:07:44

right, because the react native packager will parse your source files for require and resolve them at bundling time

anmonteiro02:07:06

but you don’t need foreign libs for those things

anmonteiro02:07:10

in fact, they won’t be used at all, because the packager is going to resolve js/requires in node_modules

jeaye02:07:42

Ok, so, for my situation, even with js/require, I'll only need externs for each of the libs.

jeaye02:07:04

With the necessary externs, :advanced should work fine.

jeaye02:07:54

@anmonteiro To be super clear, does this also mean I don't need to worry about the :requires bit of :foreign-libs, as that is all figured out through the packager?

anmonteiro02:07:19

that’s right

jeaye02:07:27

I ask all of this because the cljs website doesn't detail this at all and only documents the situation where all of this is needed.

anmonteiro02:07:30

you don’t need foreign libs at all

jeaye02:07:42

Understood, thanks a lot.

anmonteiro02:07:45

you just need a deps.cljs at the root of your classpath with an :externs entry

anmonteiro02:07:02

;; deps.cljs
{:externs ["/path/to/externs.js"]}

jeaye02:07:24

Right, with likely one js file per rn lib I'm bringing in.

anmonteiro02:07:43

just put more paths in that vector

jeaye02:07:12

Excellent. That seems much more manageable now.

lingeeal07:07:58

hi, I can add some headers for example when doing ajax requests with http/get

lingeeal07:07:48

how can I add this similar behavior to secretary/defroute "/someroute?

jazzytomato09:07:29

Hi, I am trying to require npm dependencies in a cljs project, my dependencies are like

[org.clojure/clojure "1.9.0-alpha17"]
  [org.clojure/clojurescript "1.9.671"]
the build like
:cljsbuild
  {:builds
   [{:id           "dev"
     :source-paths ["src/cljs"]
     :figwheel     {:on-jsload "myproject.core/mount-root"}
     :compiler     {:main                 myproject.core
                           :npm-deps             {:mapbox.js "3.1.1"}
and in my namespace
(ns myproject.views
  (:require [re-frame.core :as re-frame]
            ["mapbox.js" :as mapbox]))
but when running lein cljsbuild once dev it raises an exception clojure.lang.ExceptionInfo: Library name must be specified as a symbol in :require / :require-macros; offending spec: ["mapbox.js" :as mapbox] at line 1 Which I believe shouldn't happen with this version of clojurescript?

thheller10:07:15

@jazzytomato the feature is still alpha and often requires a lot of manual tuning

thheller10:07:56

I only looked briefly over the source but there are many things in there that are probably not supported

thheller10:07:43

for ["mapview.js" :as mapview] to work you might also need to specify mapview.js in :npm-deps

thheller10:07:31

but yeah the packages are plain out weird, probably not compatible with closure

jazzytomato10:07:10

sorry I meant ["mapbox.js" :as mapbox] in my namespace, updated my message

dnolen11:07:23

@jazzytomato you need to use master

jazzytomato11:07:58

aaahhhhh ok! from the blog post "ClojureScript is not an Island" I thought this was released. Thanks!!

dnolen11:07:46

no @jazzytomato, those are sneak preview posts

dnolen11:07:13

getting all the various loose ends resolved is taking some time

jazzytomato11:07:32

no worries, that's awesome anyway

jeremys12:07:53

@anmonteiro I have tried with

:language-in :ecmascript6 :language-out :ecmascript3
but it doesn’t change the outcome. Thanks for taking the time I will follow along on the jira.

taylor12:07:49

I’m writing a ClojureScript app w/Reagent/Re-frame and I’m wondering how to properly handle logout when the user’s token expires. I’m assuming I should do something like have an AJAX interceptor that checks for 401s and then dispatches a “logout” event?

mikethompson12:07:37

@taylor best to ask on #re-frame channel

jannis13:07:30

Hi! Is there a relatively simple way to generate an NPM package for a CLJS project, where the CLJS project namespaces are built into individual JS modules?

jannis13:07:50

I can think of at least one hacky way: Use shadow-cljs to build the individual JS modules, then copy them somewhere for package.json to find them.

dnolen13:07:13

I think we’re probably not actually that far away from simply using npm as a possible ClojureScript distribution mechanism - but it’s not currently in scope - shadow-cljs is probably your best bet for now.

ajpierce13:07:59

@jazzytomato I published a post yesterday about how to get some NPM libraries playing nicely in Figwheel; might not solve all of the mapbox issues, but hopefully it'll answer a question or two: https://ajpierce.github.io/posts/react-figwheel-npm/

jannis13:07:44

@dnolen Cool, thanks for the update 🙂

jannis14:07:20

@thheller Hey! How much would it take to update shadow-cljs so it can build projects that use spec.alpha? What would it take?

thheller14:07:53

@jannis what do you mean? that should just work?

thheller14:07:45

https://github.com/thheller/shadow-cljs/wiki/ClojureScript-for-node.js-libraries is probably what you want? shadow-cljs itself is build that way

jannis14:07:17

@thheller When I run it against a CLJS codebase that uses clojure.spec.gen.alpha, it doesn’t find that namespace, even if I add spec.alpha 0.1.123 to the dependencies in shadow-cljs.edn: ExecutionException: clojure.lang.ExceptionInfo: The required "clojure.spec.gen.alpha" is not available, required by "workflo/entitydb/util/operations.cljc" {:tag :shadow.cljs.build/missing-ns, :ns clojure.spec.gen.alpha, :src "workflo/entitydb/util/operations.cljc"}

jannis14:07:50

(Note: I’m running with shadow-cljs compile npm, I’m not sure that makes sense)

thheller14:07:23

let me check, it might be the aliasing of clojure->cljs

jannis14:07:14

Thanks. I took a look at the shadow-cljs source but I didn’t know where to start.

thheller14:07:05

hmm yeah the alias code for some reason doesn’t work. cljs.spec.gen.alpha works just fine

jannis14:07:45

Do you want me to file a bug? I can use cljs.spec.gen.alpha in a reader conditional for now.

jannis14:07:50

@thheller https://github.com/thheller/shadow-cljs/issues/74 - feel free to give it a better title, I wasn’t sure whether this is a general clojure->cljs aliasing issue or something more specific.

thheller14:07:48

ah just found the cause … fix incoming

lwhorton14:07:49

wrt compiler options :preloads '[my.namespace], is there something wrong I could be doing such that a namespace would get pulled into an :advanced compilation, even if the configuration doesn’t list :preloads? Would that happen if my preloaded namespace :required another namespace in my source? * for whatever reason my :preloads namespace that invokes cljs-devtools always loads into my compiled app

lwhorton16:07:47

For those interested, preloads doesn’t work the way I thought. It simply loads the namespace ahead of main.core, but it doesn’t prevent it from being loaded in case it’s not listed in :preloads at all. In addition to this, binaryage/cljs-devtools doesn’t work with DCE unless it’s setup very specifically. (either behind a goog.DEBUG, or more preferably configured via the specific namespace [devtools.preload]. So my issue was that 1) cljs-devtools wasnt configured properly and 2) DCE doesn’t happen “automagically” via the lack of a :preloads to your namespace. Your namespace will still be loaded, and if you want dev-only side effects they still need to be hidden behind (when goog.DEBUG ...).

jannis14:07:22

@thheller Awesome, thanks! 🙂

thheller14:07:06

@jannis should be fixed if you upgrade shadow-cljs

jannis14:07:40

@thheller Did you push a new release already?

jannis14:07:44

Ah, I was looking at GitHub but didn’t see the changes yet.

jannis14:07:54

@thheller Confirmed, it works. Great stuff, thanks for the quick fix!

thheller15:07:20

maybe of interest for your own package

jannis15:07:16

Yep, I’ll try that

thheller15:07:14

be careful if you are building multiple libraries that way, they won’t be able to interact with each other

jannis15:07:14

Got it. I may want to build two libraries like that but I can use them in isolation with a JS bridge inbetween.

thheller15:07:55

yeah :advanced compilation is tricky for things like this

jeaye15:07:28

Regarding :infer-externs, is there any need for extern files anymore?

dnolen15:07:24

it mostly works, but there are some edgecases

dnolen15:07:46

you off course need externs in general of course

dnolen15:07:56

:infer-externs is just convenient way to auto-generate them

jeaye15:07:58

Right, I see. So, if I were to enable :infer-externs, I'll get some extern files generated for me? The way I read it, the compiler will just tell me the externs I'm missing (which is still helpful!).

dnolen15:07:18

no the point is auto generate externs, and warn in ambiguous situations

jeaye15:07:41

Excellent, that would be amazing.

dnolen15:07:43

well people have been using it for a while, so it works

jeaye15:07:46

@dnolen Does this allow Closure to optimize my third party JS deps, and their deps, etc? That is, the extern inference extends to the JS side, not just the CLJS side?

dnolen15:07:05

there are some bugs, and some use cases don’t quite work great (singletons like jQuery)

dnolen15:07:33

@jeaye externs is synonymous with “Closure will never see it”

jeaye15:07:46

Ah, I see.

dnolen15:07:08

if you want to optimize random libs you need to use :npm-deps

dnolen15:07:52

I suspect for at least the next year it will require a lot of interacting with JS lib maintainers to make small tweaks

dnolen15:07:56

but we’ll get there eventually

jeaye15:07:03

For a react native project, I have about a dozen rn libs I'm using directly from npm; those are my only third party js deps. Should I go the :npm-deps route, or the :infer-externs route?

dnolen15:07:36

:npm-deps maybe one day

dnolen16:07:06

you don’t need :infer-externs for React Native technically - advanced compilation isn’t all that important in that environment

lwhorton16:07:32

are you suggesting we force our users to download a 4mb app instead of a 2mb app?! how barbaric 😃

jeaye16:07:41

Hm, due to a bug with RN specifically, :advanced would be needed, since it makes the JS significantly smaller.

jeaye16:07:26

Basically, some process in RN bundling is parsing the ~4MB (`:simple` optims) JS file and timing out.

jeaye16:07:01

The time it takes to parse appears to at least be exponential, so we were really hoping to shrink it down in any way possible.

dnolen16:07:10

@lwhorton it’s RN - nothing is going to be downloaded

jeaye16:07:29

Well, from the App/Play stores. 😛

dnolen16:07:28

@jeaye hrm I haven’t heard anything about this you probably want to bring it up in #cljsrn though - I don’t follow RN that much

lwhorton16:07:42

^ jeaye :thumbsup: only 1 download

jeaye16:07:01

@dnolen Right, let's assume that I've done the necessary research and this RN bug is very difficult to fix and likely easier to work around. It sounds like :infer-externs is best way to get :advanced working so I can significantly shrink my JS size?

dnolen16:07:36

I don’t know what you are trying to do?

dnolen16:07:42

if RN has externs use those

dnolen16:07:58

if not then maybe :infer-externs will work for you

jeaye16:07:22

Alright. Thanks very much for the info.

oskarkv16:07:43

When writing macros for CLJS in Clojure, and the emitted code should include namespaces that only exist in CLJS, i.e. can't be required into the macro-defining Clojure namespace, is there a less tedious way than to manually fully namespace qualify each symbol that has a CLJS namespace? For example

`(f (cljs.core.async/alts! ...))
etc

thheller17:07:43

fully qualifying is definitely safest

darwin17:07:47

hmm, I usually tend to expose macros to my cljs code via a “gateway” cljs namespace, and make sure that the “gateway” cljs namespace requires all possibly required cljs namespaces for code generated from all possible macros… this removes burden from users of my macros to remember what namespaces to require

darwin17:07:43

oh, but my answer is not really related to your question 😉

oskarkv17:07:48

@darwin Oh, yeah that seems good. But my problem is that in the macro itself I have to fully qualify everything.

oskarkv17:07:09

And what if I want the macro to work for both Clojure and ClojureScript

oskarkv17:07:39

In the case of core.async, it's just the namespace name that differs

darwin17:07:56

macros return “forms” as data, so you could be able to write some generic function to walk that data and rewrite clojure-specific namespaces to cljs namespaces depending on current environment

darwin17:07:59

maybe a bad idea

oskarkv17:07:07

I was thinking the same

darwin17:07:11

but this would allow you to write the code once without conditionals

darwin17:07:06

once I wrote this to avoid writing platform-specific code for try-catch: https://github.com/binaryage/env-config/blob/master/src/lib/env_config/impl/macros.clj

lwhorton17:07:40

npm offers :peerDependencies to say “i need this library of this version but I will not include it myself”, does cljs offer something similar? I would imagine something like maven’s :scope "provided" but I’m not so sure that’s working as I expect.

deadghost17:07:17

can I asyncify a function call?

deadghost17:07:33

I end up calling do a dispatch with re-frame that calls a function that does a dispatch-syncdown the line

deadghost17:07:01

and dispatch with a dispatch-sync in it is a no-no

deadghost17:07:29

I want to kick off the function call in a way that says we're done with the dispatch and have the function run without further relations to the calling handler

lwhorton17:07:43

what are you trying to do @deadghost? generally dispatch-sync is reserved for 1 dispatch at the very beginning of the bootstrap, and then maybe for unit testing

deadghost17:07:06

I'm already using re-frame-async-flow

deadghost17:07:32

I'm using re-frame with pushy which does history/push-state handling

deadghost17:07:51

well bidi/re-frame/pushy

deadghost17:07:50

each app path has an associated boot fn and mount fn

deadghost17:07:34

so when the url changes, the boot handler gets called with dispatch-sync before the mount fn is called

deadghost17:07:11

this is to make sure the data is loaded before the first mount

deadghost17:07:37

this normally works ok except when I'm changing the url via a handler

deadghost17:07:12

changing the url calls a function that ends up hitting that dispatch-sync

deadghost17:07:44

or rather calling the function to change the url hits the dispatch-sync

deadghost17:07:38

I'm not familiar with forward-events-fx though so maybe that's what I want, idk, looking

deadghost18:07:49

right now I'm thinking I may be able to deal with this by cramming in core.async

jeremys18:07:35

@dnolen @anmonteiro Hey guys I just saw you committed a fix for CLJS-2279. Thanks for being so reactive. I brought this up yesterday, less than 24 h and a fix. So cool, thx again.

deadghost20:07:53

yep core.async did the trick, need to get around to wrapping it in a custom -fx though but whatever

mobileink21:07:17

Anybody know if there is a way to make ES6 class methods directly delegate to a Clojurescript implementation ns? By “directly”, I mean I would like to just have something like foo: my.delegate.foo or some such, rather than foo() { my.delegate.foo() }. (not even close to a JS expert, in case it isn’t obvious). The idea is to have something like gen-class with :impl-ns, if that makes sense. The ES6 class would be generated (from Clojure code), and delegate to a user-defined implementation ns. Works fine with pre-ES6, trying to figure out how to do same without writing ES6 class code in pre-ES6 syntax.

dnolen21:07:55

that’s a problem in JS fundamentally

mobileink21:07:46

somehow I’m not surprised. boy, I hate to have to figure out how to write ES6 classes in pre-ES6!

mobileink21:07:45

er, I guess the advice is to not spend a whole lot of time trying to do it as I described?

mobileink21:07:48

if I have foo() { my.delegate.bar(); } in my ES6 class, would calls to foo get optimized away in :advanced (converted to calls to my.delegate.bar())?

rgdelato21:07:22

If your class is something like:

class Fooer {
  foo() { my.delegate.bar(); }
}
...I think you should be able to do:
Fooer.prototype.foo = my.delegate.bar;
...if you're worried about the extra function wrapper. (Though I guess it's not exactly the same if you want to make sure you receive zero arguments.)

mobileink21:07:01

i.e. class Fooer {} Fooer.prototypep.foo = my.delegate.bar (leave the method defns out of the body, add them with prototype assignments?)

rgdelato21:07:36

yeah, I think that should work

mobileink21:07:55

i.e. mix ES6 and pre-ES6? never thought of that, buy why not?

mobileink21:07:33

what really matters is having the right args to customElements.define

mobileink21:07:44

(this is for webcomponents, btw)

mobileink21:07:13

that sounds like a great idea, at least to experiment with. reading the google on how to express ES6 classes in pre-ES6 gave me a headache. But I think the only ES6 I really need is class Foo. maybe.

alice21:07:34

So I'm sending a request to my rest service for some information that it fetches from a DB and sends back to me, but it takes 2 or 3 seconds to return and I end up with a 500 server error, even though it eventually sends the information

alice21:07:10

For some more information, here's my Clojure and Clojurescript

alice21:07:28

(very much in development)

alice21:07:35

(let [user (future
                              (first (filter
                                       #(and (hs/check (:email (:params req)) (:email-hash %))
                                             (hs/check (:password (:params req)) (:password-hash %)))
                                       (mc/find-maps db "users"))))
                       auth (:auth-conf req)
                       exp (-> (t/plus (t/now) (t/days 30)) (to-timestamp))
                       token (jwt/sign {:user (dissoc @user :_id)} (pkey auth) {:alg :rs256 :exp exp})]
                   (println @user)
                   (mc/update db "users" {:username (:username @user)} {$set {:session token}})
                   (respond! 201 {:token token :age 2592000}))
This is the back end

alice21:07:06

And the cljs

(go (let [response (<! (http/post (str url "create-auth-token")
                                    {:with-credentials? false
                                     :headers           {"content-type" "application/json"}
                                     :json-params       {:email email :password password}}))
            body     (:body response)
            token    (:token body)]
        (if (= nil (:token body))
          "Something went wrong."
          (do
            (cookies/set! :session token :max-age (:age body))
            (re-frame/dispatch [:set-active-panel :home-panel])))))

alice21:07:49

Has anyone else seen similar issues

alice21:07:03

Information on async http in clojurescript appreciated

mobileink21:07:32

@rgdelato just tried it (using JS only) and it works! thanks so much!

rgdelato21:07:43

no problem, glad to help!

thheller21:07:53

@mobileink you can write web components without classes just fine

thheller21:07:18

a macro could certainly remove some of the nasty details

mobileink21:07:22

@thheller I remember you mention this a while back, but I understand js/Reflect is a little iffy?

mobileink21:07:26

anyway, just writing class Foo {} and then some prototype assignments seems so much easier and more reliable than unpacking the whole mess into pre-ES6.

thheller21:07:14

I think support is much better these days

mobileink21:07:20

(plus, I’m trying as hard as I can to remain ignorant of Javascript, heh)

sundarj21:07:54

as someone who knows js pretty deeply, that is a wise decision

mobileink21:07:45

(i figure even if I eventually grok stuff like js/Object.create etc. something will eventually byte me in the arse)

rgdelato21:07:50

@mobileink if you turn that class into a function, the whole thing -is- the pre-ES6 version!:

// ES5 version
var Fooer = function () {};
Fooer.prototype.foo = my.delegate.bar;

mobileink21:07:39

ok, but doesn’t class (not to mention extends) do a bunch of other stuff, the details of which are best left unmentioned?

rgdelato21:07:13

Yeah, extends does a bunch of other stuff. But class not so much

thheller21:07:19

thats the stuff Object.create does 😉

sundarj21:07:52

it's just syntax sugar

mobileink21:07:22

i.e. customeElements.define wants a class. If I can get away with class Foo plus some assignments, then I do not need to grok the (undeniable imho) complexity of e.g. https://scotch.io/tutorials/better-javascript-with-es6-pt-ii-a-deep-dive-into-classes

mobileink21:07:44

@sundarj define “just” 😉

mobileink21:07:42

NB: core.async is also “just” sugar, no?

sundarj21:07:25

what i meant by 'just' is that anything you can do with a class, you can do with plain functions 😅

jeremys21:07:26

Hey guys, still playing with the new :npm-deps feature, and I ran into another problem. When I :require ["@material/textfield/foundation"] now the code compiles (thanks to CLJS-2279). But there is now an issue at run time. The javascript files required by “node_modules/@material/textfield/foundation.js” in its es6 import statements aren’t taken into account. They don’t make it to my :output-dir and I get in the js console of the web browser the error Undefined nameToPath for module$$material$base

sundarj21:07:35

probably not the best choice of words on my part 😄

mobileink21:07:37

@sundarj understood, not whining, thanks for the input. for the moment, I’m going to mix ES6 and pre-ES6 just to minimize the code complexity (for me at least) and see what happens. I may be back. 😉

dnolen22:07:06

@jeremys make something minimal and report it in JIRA please - not sure if anyone will have time to look at it today, but at least it will give us something to track.

dnolen22:07:35

when reporting it’s preferable that the minimal case not include outside tooling - in your case your should be able to replicate the problem with the QuickStart ClojureScript JAR

dnolen22:07:41

that will save everyone a lot of time

jeremys22:07:45

@dnolen Ok no problem I’ll work on a minimal repo and post to jira.

dnolen22:07:05

for the next couple of months if you encounter :npm-deps issues please report here first - so someone can screen it - then take it to JIRA if requested

dnolen22:07:07

it’s going to take a while to figure out what we should do as there so little standardization in NPM, but I believe we can cover many interesting / popular libraries

dnolen22:07:24

in particular we’re interested in libraries with functionality not already covered by ClojureScript or Google Closure

dnolen22:07:36

less interested in things which dupe known functionality

colindresj22:07:02

Excited for the new release! How would one use yarn instead of npm? Is there a :yarn-deps flag or something like that?

mobileink22:07:04

my stupid question of the day: just compiled some misnamed clojurescript - file is my-app/delegate.cljs, with namespace my-project.foo. I believe that would blow up in Clojure? but it compiles in cljs. (following the basic instructions at quick-start) Wondering why it compiles?

jeremys22:07:32

@dnolen my pleasure, plus I’d really like to make these material component web stuff work and since it is a google thing it is supposed to play well with closure compiler...

dnolen22:07:17

@mobileink it was unclear six years ago whether we should be classpath or file system oriented - so that works - and it’s not going to change now

dnolen22:07:10

all we care about for resolution is node_modules

mobileink22:07:16

thanks. (note to self: document this)

dnolen22:07:32

so you could manage your JS packages yourself and just :require them

colindresj22:07:35

Oh ok, so the :npm-deps flag is just about establishing which node modules can be used in :require. In other words, it’s still up to us to npm install or yarn add

dnolen22:07:31

:npm-deps is for people who don’t care about yarn since from a ClojureScript perspective it’s not necessarily relevant - esp. in the long run

dnolen22:07:43

:npm-deps supports upstream deps

dnolen22:07:16

so you could depend on a CLJS library that declares an NPM dep, and then ask the ClojureScript compiler to install it via npm tool

dnolen22:07:42

my point is just that we’ve separated getting stuff, from resolving :require

colindresj22:07:58

Ah ok, makes sense

dnolen22:07:33

we may allow plugging in yarn later - but it’s really not that important right now

dnolen22:07:41

first step is to sort out what libraries people want to use and what doesn’t work

colindresj22:07:13

Yeah that’s cool, just being able to set npm-deps, then have it all work seems like the main use case

colindresj22:07:35

Personally don’t care too much if node modules are coming via yarn or not, but wanted to know what that would be like

dnolen22:07:04

@jeremys poking around on https://github.com/material-components/material-components-web, your assessment does seem correct, it looks like not only should it work Closure, but designed for it

dnolen22:07:17

@anmonteiro I wonder if the issue here is that module_deps.js resolution can’t follow through ES6 import so we can’t compute the inputs to pass into Closure?

anmonteiro22:07:48

@dnolen that seems like a fair assessment

anmonteiro22:07:18

I'll look into seeing how we can solve that later

dnolen22:07:14

@anmonteiro looks like module-deps supports this, can transform before resolve

anmonteiro22:07:57

Cool, then shouldn't be hard to plug it in

dnolen22:07:17

I'll file an issue to track

anmonteiro22:07:29

I'm not at the computer until later but can look into it. If not today, tomorrow

dnolen22:07:53

No rush, we've been going crazy on this stuff :)

dnolen22:07:31

not sure when we’ll get to it but we understand the problem

jeremys22:07:16

@dnolen Thanks for creating the jira ticket

mobileink23:07:25

O frabjous day! Thanks to @rgdelato, that beamish boy, I’ve got straighforward delegation from ES6 class declarations to cljs implementations working! Callooh! Callay! At least I think I do. If you want to play, see https://github.com/miraj-project/psk2. (this is just js/cljs for experimentation, not miraj) Note that there is a problem involving load ordering - see the NOTE in the middle of src/my-app.html. I’ll prolly need help figuring that out, and it could end up being pretty complex once you add code-splitting and multiple webcomponents.