This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-29
Channels
- # aws (3)
- # beginners (160)
- # boot (2)
- # bristol-clojurians (3)
- # cider (62)
- # cljs-dev (77)
- # cljsrn (15)
- # clojure (147)
- # clojure-brasil (10)
- # clojure-dusseldorf (2)
- # clojure-gamedev (1)
- # clojure-italy (128)
- # clojure-russia (1)
- # clojure-spec (19)
- # clojure-uk (34)
- # clojurescript (408)
- # code-reviews (2)
- # component (1)
- # core-async (56)
- # cursive (1)
- # datascript (1)
- # datomic (81)
- # emacs (11)
- # fulcro (39)
- # java (16)
- # jobs (3)
- # lein-figwheel (2)
- # leiningen (6)
- # lumo (89)
- # off-topic (11)
- # om (2)
- # om-next (1)
- # onyx (17)
- # parinfer (4)
- # pedestal (3)
- # perun (1)
- # quil (3)
- # re-frame (19)
- # reagent (8)
- # reitit (5)
- # remote-jobs (5)
- # shadow-cljs (145)
- # spacemacs (1)
- # sql (7)
- # test-check (15)
- # uncomplicate (1)
- # unrepl (122)
- # vim (2)
- # yada (4)
@dnolen the fix for pg test case is ready: https://dev.clojure.org/jira/browse/CLJS-2669
Question. Does hinting on return object works currently?
(defn my-fn [x] ^js/Foo.Bar
...)
@juhoteperi applied
@dnolen so yes it works?
I mean, I see I have warnings here, but that's ok, I can open an issue in case
actually I think my issue is a bit different, see
(defonce parent-logger
(.createLogger bunyan #js {:name "ep-cloud" :serializers bunyan/stdSerializers}))
I need to type hint both after .createLogger
and at the defonce
level I guess@dnolen how do you mean? It is in my :npm-deps
I am on node
well, I am experimenting, my payload will go in a lambda, so size might matter
wise man lol 😄 I just wanted to play 🙂
If you happen to be pushing cljs code between contexts that require serialization (granted, not a common use case), advance compiled can be way faster
also, this performance gain would be only visible during cold startup
but I wanted to see how far I could get, definitely not worth too much time on it
and only if parse time dominates, but I never saw a huge difference between simple and advanced
yep will take your advice, seems though the return type hinting is not really effective in some case...
will try to make a simpler repro if i can
well you provide a feature, I was just giving feedback 😄
@dnolen you want this added to the website?
[NOTE]
====
Note: When compiling in `:advanced` mode, ClojureScript source code
files will not be included in the `:output-to` directory. This is
so that source files are not inadvertently exposed in production.
====
Sounds good. I may ask about some more help does on occasion. I'd like to try to capture some of the questions coming through the channels in our docs, when it makes sense.
I think a good rule of thumb is that we shouldn’t be replicating general web application stuff into our docs
Let's say I want to provide a cljs library that internally depends on an npm package(s).
With latest cljs consuming npm packages is like a breeze. One can either use :npm-deps
map and :install-deps
options and let the cljs compiler to install npm dependencies, or use well known tools in js world (npm, yarn) and install dependencies manually. The key is to provide node_modules directory. But this works on the project level only. How to note, describe, provide the information that the library depends on an npm package in the specific version range?
The first option is better for my idea as it's standard way and :npm-deps map could be copied to deps.edn
file. If so, the cljs compiler could gather these npm dependencies from project and all libraries, create a dependency graph (would be tricky, I know), install them and compile the project. But it has drawbacks such as npm outdated
does not work.
Second option uses the power of existing tooling, but it would require to include package.json
file in jar. Then the same cljs compiler actions described in first option applies.
General problem is that js can depend on multiple versions of one library at the same time; cljs can't as its dependencies are flat.
I'd like to know your thoughts 🙂
Cool, I didn't know there's already support for upstream :npm-deps
upstream npm-deps does not work for me - library (jar) contains deps.edn with {:npm-deps {"legendary-spoon" "0.0.1"}}
and project depends on this library. Compilation fails, adding :install-deps true
to project changes nothing
@honzabrecka can you put together a minimal repro?
@john working on it
repo with minimal repro https://github.com/honzabrecka/cljs-npm-deps-test
@honzabrecka I think David was referring to deps.cljs
and not deps.edn
@richiardiandrea good catch, thanks!
last weeks there's deps.edn
everywhere, so I totally overlooked that cljs extension 😄
so it works of course 🙂
so for transitive npm deps you need deps.cljs
, maybe that file could be auto generated from :npm-deps
? Sorry maybe I state the obvious here 😄
as usual
ah ah! wow this reads so odd 🙂
as far as I observed the deps.cljs
is not generated
yep I suspected that