This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-09
Channels
- # aleph (21)
- # architecture (5)
- # boot (25)
- # cider (1)
- # cljs-dev (115)
- # clojure (59)
- # clojure-brasil (3)
- # clojure-dev (4)
- # clojure-italy (20)
- # clojure-nl (2)
- # clojure-portugal (6)
- # clojure-russia (12)
- # clojure-spec (43)
- # clojure-uk (37)
- # clojurescript (76)
- # datomic (123)
- # emacs (3)
- # graphql (2)
- # hoplon (5)
- # jobs-discuss (1)
- # jobs-rus (4)
- # keechma (7)
- # lein-figwheel (13)
- # leiningen (7)
- # lumo (2)
- # off-topic (17)
- # om (6)
- # onyx (26)
- # parinfer (19)
- # planck (2)
- # re-frame (80)
- # reagent (9)
- # ring (1)
- # spacemacs (45)
- # testing (1)
- # vim (28)
this took me by surprise: https://dev.clojure.org/jira/browse/CLJS-2312
@kommen probably just an oversight, though I am surprised it wasn’t caught by @anmonteiro work on this
we should munge reserved keywords consistently as long you haven’t set :language-out
to >= :es5
yeah, I was surprised that just requiring the compiler apparently changes how stuff is munged
so it happens for me when compiling the sample with uberjar built from the current master
@dnolen oh you were right: it’s actually an issue with :language-out
and unrelated to any requires. I just didn’t catch this as changing the :language-out
option doesn’t recompile the file without killing the out directory first
So my work on default
was after 1.9.854
This seems jnrelated
Unless @kommen built from master?
@anmonteiro yep, I built from master
I see, that wasn’t clear
probably a bug in my patch then
I’ll look into it before Friday
that’s not valid ES5
if you notice my commit: https://github.com/clojure/clojurescript/commit/aff39caac5f512fdeda7ad41cdd6224d2d4ca48f
I renamed every param named default
so the problem here is that we may only want to allow default
as a property access
@anmonteiro did you miss this occurrence of default i linked to in the issue?
probably
@anmonteiro maybe this wasn’t in your patch, but I do think related - we should consistently munge default
if the language is not >= :es5
.
I think we’re doing that
or, I’m pretty sure we’re always munging default
but there’s definitely a bug here
even when language >= :es5
we can’t just not munge default
because it’s only allowed as a property access
function foo(default) {console.log(default)}
is not valid ES5
but someObject.default()
is
@dnolen does this make sense?
@anmonteiro ah right, yes
cool, working on a fix
and a regression test, ofc
@anmonteiro what about deftype
fields?
I may not have enough context about those
my decision was that we should warn if people create JS deftype
with reserved field names
is it this one? https://dev.clojure.org/jira/browse/CLJS-2236
the only tricky thing I think is that we need to be careful with deftype constructor fn
“default constructor”?
ah got it
totally
I think we should fix the immediate bug that @kommen reported
because it’s pretty bad and shouldn’t be included in the release
and worry about the deftype
things later
since it’s not a regression we introduced between 1.9.854 and current master
actually a good regression test is just reverting all those default
renames
@dnolen patch attached
I think it’s safe to assume that if var-name
has a namespace, we’re going to emit dotted property access
so we don’t need to munge default
in those cases
Is that what this option does? https://clojurescript.org/reference/compiler-options#install-deps
What confuses me is the docs for :npm-deps
indicates Used to install NPM dependencies on behalf of the user.
Perhaps it should say something used to declare? Hmm.
totally
it used to install the deps
but we changed the default behavior
we have simple conflict detection
@mhuebert here’s the thing. :npm-deps
is supposed to be used for very simple use cases
I’ll submit a PR that removes the sentence. If accepted it would read
Declare NPM dependencies. A map of NPM package names to the desired versions. See also :install-deps
.
if you have a more complex setup, just install the dependencies yourself
and require them in your ClojureScript code
The CLJS compiler is smart enough to know which things are node_modules
so putting things in node_modules is the equivalent of adding something to the classpath
I guess you could put it that way
@mhuebert we have a test for that https://github.com/clojure/clojurescript/blob/master/src/test/clojure/cljs/build_api_tests.clj#L402-L428
maybe that can help you set things up
note that installing @cljs-oss/module-deps
and konan
is required if you’re targeting the browser
Here is the :npm-deps
site doc change PR: https://github.com/clojure/clojurescript-site/pull/135
@anmonteiro huh I see they just tagged Closure Compiler, is that pre your patch?
Looking
@dnolen unfortunately yes. Well. It has the simple usage
Not yesterday's patch though
@anmonteiro I guess they do have SNAPSHOT releases?
Yeah but that's risky
Their snapshot is always 1.0-SNAPSHOT
and updated on every CI run
So a broken commit and you're done
Having our own artifact would let us track master or whatever revision works best for us
gotcha