This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-12
Channels
- # bangalore-clj (1)
- # beginners (27)
- # boot (29)
- # clara (4)
- # cljs-dev (10)
- # cljsrn (2)
- # clojure (36)
- # clojure-austin (9)
- # clojure-brasil (4)
- # clojure-france (10)
- # clojure-nl (2)
- # clojure-quebec (1)
- # clojure-russia (10)
- # clojure-spec (48)
- # clojure-uk (6)
- # clojurescript (82)
- # clr (4)
- # core-async (5)
- # core-logic (3)
- # cursive (4)
- # datomic (1)
- # devcards (1)
- # figwheel (1)
- # leiningen (2)
- # lumo (6)
- # off-topic (23)
- # om (39)
- # onyx (3)
- # planck (2)
- # re-frame (5)
- # reagent (24)
- # specter (1)
- # test-check (3)
it turns out that lein correctly reports some compiler fail, but boot-cljs doesn't. i made a minimal poc at: https://github.com/FossiFoo/cljs-compile-poc
@juhoteperi you seemed interested, maybe you want to have a look it
is there any way to get a list of the namespaces required by a namespace? it’s possible to get those whose require clause uses :as or :refers, but i don’t see how to detect e.g. (:require [foo.bar]).
mmm...not that I know of
@alandipert and @micha would you be interested in having a boot-maintained version of cemerick/pomegranate
? I have upgraded aether in there https://github.com/cemerick/pomegranate/pull/80 but I don't know if things have been merged lately.
I am using in another project as well, but I thought I might ask here as well before deploying my own fork
@richiardiandrea are there tings we need in the new aether version?
@micha there is a substantial changelog yes, but I haven't investigated implications in boot. But I will. In general the whole redesign of Aether might have sped up things (or not), it is worth having a look for sure. Link -> http://wiki.eclipse.org/Aether/New_and_Noteworthy#1.1.0_.28NOT-YET-RELEASED.29
btw my patch upgrades to 1.1.0
quite painlessly, I am using it in a maven plugin that resolves clojure dependencies
@micha no they changed names before 1.1.0
, which now has new name and many fixes
there is a nice fix: DefaultRepositorySystem.resolveDependencies() fails with NPE when dependency collection fails early and yields not even a root node
we could triage it, I will probably need to deploy it to clojars anyways, if they don't merge it in cemerick/pomegranate
I also understand the "it is another thing maintain" counter-argument though 😄
This is also nice https://bugs.eclipse.org/bugs/show_bug.cgi?id=421906: > Currently, the checksums retrieved during artifact resolution are stored locally next to the actual data file. I doubt that many applications have use for those files so it would be nice to have an option to not persist the checkums locally, thereby saving a few inodes/blocks (I personally have ~27,000 checksum files in my local repository, occupying > 100 MB of disk space for what's actually just 1 MB of real data)
or https://bugs.eclipse.org/bugs/show_bug.cgi?id=424586: > Cyclic dependencies indicate a flaw in the project setup of the affected artifacts that should be communicated to the end user to enable him to fix the problem. Whether cycles are generally tolerated and only cause warnings or denote errors is up to the application to decide but Aether needs to report cycles while building a dependency graph.
Ok I'll stop spamming 😄
Last one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=379675 "Version ranges with non-snapshot bounds should not resolve snapshot versions"
hey all, I'm trying to follow https://clojurescript.org/guides/javascript-modules#babel-transforms using boot, but am running into WARNING: Unsupported preprocess value :jsx for foreign library src/js/hello.js. null
am I missing something obvious? https://github.com/craigy/cljc-app/blob/master/build.boot#L17
@skynet I am not 100% of what I am about to say and I would ping Juho for confirming it, but boot-cljs
might run in a pod, which means that it does not "see" the defmethod
you have in boot.user
A quick test you could try is to add it to some namespace in your src
yeah it looks to me like boot-cljs
creates a pod for the compiler, so it may be impossible to add a preprocessor without modifying it
@skynet It looks like it