This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-29
Channels
- # aws (1)
- # aws-lambda (1)
- # beginners (34)
- # boot (61)
- # cljs-dev (126)
- # cljsjs (10)
- # cljsrn (4)
- # clojure (27)
- # clojure-russia (7)
- # clojure-spec (1)
- # clojure-uk (26)
- # clojurescript (42)
- # cursive (31)
- # datascript (4)
- # datomic (16)
- # hoplon (51)
- # klipse (1)
- # lein-figwheel (1)
- # lumo (79)
- # off-topic (16)
- # om (7)
- # parinfer (5)
- # planck (2)
- # re-frame (6)
- # reagent (3)
- # ring-swagger (5)
- # untangled (11)
@alexmiller i think it makes sense that that works in clojure
@dnolen other than historical reasons, are there any hurdles to making use
work just like in Clojure?
i.e. not being limited to just :only
right, but besides that. It would be feasible right?
I'm just interested in understanding if there would be any technical limitations to implementing such thing
@anmonteiro the filename _dirname thing hasn't been resolved I don't think
d.nolen: would you take a PR that adds a spec for compiler options? would like to start tracking them for autodocs
@bhauman hrm, what are you seeing that seems wrong?
@shaunlebron: no not until it's clear closure.spec is settling down
@anmonteiro just wondering if you got my message
sorry, I read what you wrote above
can you tell me what steps I need to take in order to repro it?
busy now but can take a look later
simple repro: use earlier cljs ex. 1.9.229 create a node project with a cljs file (def loadtime-path js/filename) (defn runtime-path [] js/filename) compare the results to cljs 1.9.459
I'm working around it, but I have to say its tough to work with relative paths etc in node without it
it would be more productive to see if a different approach for node_bootstrap.js
is needed
and I can guarantee what we currently have is going to get tweaked over the next couple of weeks
@dnolen what's the story like for people who have JSX stuff and want to call cljs.build.api/node-inputs
?
doesn't seem like the script can run because it can't parse the JSX file
sure, makes sense. but the automatic foreign-lib entry generation can't be used in this case
@anmonteiro it can
hrm I'm feeling I asked the wrong question
or you didn't understand what I wanted to ask
right, I still think we're not in sync
the script you call with JSONStream and such
exactly
right. deps shouldn't change that often
I am more concerned about the related case more people are going to want - the entry point is ClojureScript
probably when we think about that we might want to consider what to do about ES6/JSX/etc. entry points
what doesn't work now, given that use case?
automatically figuring out what entries to put if you only require it from CLJS?
right, exactly
but you can still do it somehow, right?
it's just hard
I was thinking: 1. create some JS file which requires all those node modules 2. compute an edn file with the foreign lib entries 3. use that and don't compile the JS file with the requires
hrm I don’t know exactly how we’re going to do it - going to require some serious thought
what I was saying was only from a specific application point of view
but there's no :provides
entry in that generated thing
@bhauman so the problem with __filename
and __dirname
is that these just have to be locals
goog.provide
is supposed to write to global
but everything I try just doesn’t seem to work
prior to this release we did use Node.js require
for everything except goog/base.js
and foreign libs