This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-11
Channels
- # adventofcode (116)
- # aleph (10)
- # announcements (2)
- # beginners (67)
- # boot (3)
- # calva (17)
- # cider (8)
- # cljdoc (27)
- # cljsrn (6)
- # clojure (144)
- # clojure-austin (3)
- # clojure-boston (1)
- # clojure-dev (25)
- # clojure-europe (4)
- # clojure-italy (26)
- # clojure-losangeles (4)
- # clojure-nl (28)
- # clojure-russia (1)
- # clojure-uk (34)
- # clojurescript (130)
- # cursive (20)
- # datomic (69)
- # emacs (14)
- # figwheel-main (2)
- # fulcro (31)
- # graphql (3)
- # hyperfiddle (3)
- # jobs (1)
- # jobs-discuss (1)
- # kaocha (1)
- # leiningen (2)
- # lumo (2)
- # nrepl (1)
- # off-topic (182)
- # onyx (5)
- # re-frame (88)
- # reagent (12)
- # reitit (2)
- # ring-swagger (13)
- # shadow-cljs (136)
- # tools-deps (28)
- # vim (4)
has anyone here successfully made a lambda function with shadow-cljs that calls the aws sdk?
@royalaid let me know when you do. there are a couple of gotchas I can help you with.
this means you must install the bluebird
npm package. no idea how to do that for AWS though.
I just have to copy the node_modules into the target directory and zip the whole thing up before I send it up to lambda. shouldn't be a big deal. Thanks so much for that insight, that's really helpful
@idiomancy I have seen some discussions about how mixing externs and shadow's built in ways to resolve them can cause problems. I have also just recently experienced that it sometimes matters what kind of target you are using. Looking at the promesa source code I see this: https://github.com/funcool/promesa/blob/547d01652f335df18d4f2950efc8e7caba416fbb/assets/deps.cljs#L5 It might and might not be what is biting you. I guess one way to find out is to try build the promesa library yourself, using shadow-cljs.
Maybe check what the Shadow User Guide says about externs first. Might be some way to configure around the problem you are seeing.
But since it is in a cljs library you are using, I somehow doubt that there is an easy solution.
If you build promesa using shadow-cljs it will take care of externalizing stuff. What I had in mind was trying to just put the promesa code in your src path and let it be part of your build (as an experiment).
Full disclosure: I am a shadow-cljs noob (and Clojure(Script) noob as well). I am just trying to piece together whatever clues and hints I have picked up so far.
This looks interesting (from the user guide): > With :auto the compiler will perform additional checks at compile time for your files only. It won’t warn you about possible externs issues in library code. :all will enable it for everthing but be aware that you may get a lot of warnings.
alright.. building with the bluebird assets in and compiler options set... lets giver er a whirl
this is never necessary. if it is its a bug but so far I had no reports that there are any issues.
externs have nothing to do with cannot fine module bluebird
. thats just means the the npm
package bluebird
is not found by node. they are not bundled in node build (unlike browser builds)
externs only affect the renaming of JS code. so if you get weird errors like zy.Fp
is not a function or undefined or whatever that is most likely caused by externs.
@thheller Do you have any idea what my ”Reference error clojure is not defined” could be about, when I use cljfmt
in my npm-module build?
When I build with target npm-module I seem to need to require things like clojure.string or I get this reference error. (I didn't need that with the node-library build.) That's not a problem, but it also seems to extend to libraries I use. So when cljfmt
reaches certain paths in its code it croaks with the reference error of clojure not being defined.
the code is bundled differently for :npm-module
and is more sensitive to use-without-require type of code problems.
so most likely something in cljfmt
uses clojure.string
(or something similar) but does not :require
it in its ns
OK. I'll do that. Wasn't sure it was an error to use cljoure.string without requiring it.
I also have this problem with regular expressions: https://clojurians.slack.com/archives/C6N245JGG/p1544256572353800
does it fail when you put it into a file that is loaded on startup regularly without a REPL even being attached?
I didn't have any repl attached when I tried now. Just built the extension with shadow's watcher and loaded it.
No, I get ”invalid escape”. Very strange. I have the same on two of my computers. In any case it is now a shadow issue, which I thought at first.
I do have yet another issue though… I can't require my npm-module from an npm install
. Only if I npm link
it locally.
I'm sorry. It is the whole problem. And not an error report, I think. It is rather me not being able to figure out how to do it. To me it looks like I am doing what you showed me (`npm i @shadow-cljs/npm-module-demo` then require("@shadow-cljs/npm-module-demo")
). In my case I do
const formatter = require('@cospaia/calva-lib/lib/calva.fmt.formatter');
But it does not work from an npm install
only from an npm link
.always say what happens when something doesn't work. just saying "it does not work" is not very useful on its own.
Activating extension 'cospaia.calva-fmt' failed: Cannot find module '@cospaia/calva-lib/lib/calva.fmt.formatter'.
Again, if I npm link it locally, it works (as in no complaints) and the extension does what it should do (minus croaking on certain input due to that cljfmt
thing that I need to fix).
when you install it. does the file node_modules/@cospaia/calva-lib/lib/calva.fmt.formatter.js
exist?
you may just not package the files properly for npm when creating the actual package?
npm link is just a symlink so it will contain files that may not the in the package otherwise
I just upgraded to 2.7.8 and i am getting this warning when running a build with :bootstrap
target
[2018-12-11 13:01:18.740 - WARNING] :shadow.cljs.devtools.server.util/handle-ex - {:msg {:type :start-autobuild}}
AssertionError Assert failed: (symbol? current-ns)
shadow.build.cljs-hacks/shadow-js-access-global (cljs_hacks.cljc:16)
shadow.build.cljs-hacks/shadow-js-access-global (cljs_hacks.cljc:16)
shadow.build.cljs-hacks/shadow-resolve-var (cljs_hacks.cljc:167)
shadow.build.cljs-hacks/shadow-resolve-var (cljs_hacks.cljc:131)
shadow.build.cljs-hacks/shadow-resolve-var (cljs_hacks.cljc:135)
shadow.build.cljs-hacks/shadow-resolve-var (cljs_hacks.cljc:131)
cljs.analyzer/resolve-symbol/fn--2589 (analyzer.cljc:3910)
cljs.analyzer/resolve-symbol (analyzer.cljc:3909)
cljs.analyzer/resolve-symbol (analyzer.cljc:3905)
clojure.tools.reader/syntax-quote* (reader.clj:705)
clojure.tools.reader/syntax-quote* (reader.clj:693)
clojure.tools.reader/expand-list (reader.clj:623)
any ideas of where i should start looking to get rid of it?
thanks in advance..@fj.abanses in the shadow-cljs clj-repl
try (def x (shadow/compile! :the-build-id {}))
How is the experience for shadow-cljs users when integrating JSX modules into a CLJS project?
JSX is not supported, so you need to run babel separately. but works ok-ish https://github.com/shadow-cljs/examples/tree/master/babel
hi @thheller it is on my side, an ns started complaining when compiled... nearly got the culprit 🙂 thanks, apologies for the noise!
Is it easy to replace figwheel with shadow-cljs in a project generated by a leinegan template?
well it doesn't matter what kind of project you have. you need to get familiar with shadow-cljs and how that works regardless. when you know how it works it is easy to switch the project yes.
[:app] Configuring build.
-> build target: :browser stage: :configure
<- build target: :browser stage: :configure (2 ms)
[:app] Compiling ...
-> Analyzing Module: :app
[:app] Build failure:
The required namespace "day8.re-frame.tracing" is not available, it was required by "dbiz_health/commom/events.cljs".
try re-frame.trace
https://github.com/Day8/re-frame/blob/master/src/re_frame/trace.cljc
Oah, problem solved, i just forgot to migrate a dependency from the :dev profile to the main deps of shadow-cljs.edn
------ WARNING #1 --------------------------------------------------------------
File: bidi/bidi.cljc:29:12
--------------------------------------------------------------------------------
26 | actually a valid UUID (this is handled by the route matching logic)."
27 | [s]
28 | #?(:clj (java.util.UUID/fromString s)
29 | :cljs (cljs.core.UUID. s)))
------------------^-------------------------------------------------------------
Wrong number of args (1) passed to cljs.core.UUID
--------------------------------------------------------------------------------
30 |
31 | ;; When forming paths, parameters are encoded into the URI according to
32 | ;; the parameter value type.
33 |
--------------------------------------------------------------------------------
Someone knows how to solve this?@morgancmartin Hey, can you share with me the fork you used to solve the bidi problem?
i’m referring to this: https://github.com/juxt/bidi/pull/190
Nvm, i just solved the problem by following this tutorial: https://stackoverflow.com/questions/17497937/patch-library-from-clojars
@mateus.pimentel.w its just a warning also. no impact on runtime.