This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-19
Channels
- # aleph (3)
- # beginners (90)
- # boot (1)
- # cider (1)
- # cljdoc (23)
- # clojars (1)
- # clojure (91)
- # clojure-dev (8)
- # clojure-greece (1)
- # clojure-italy (17)
- # clojure-japan (1)
- # clojure-nl (6)
- # clojure-spec (4)
- # clojure-uk (89)
- # clojurescript (48)
- # core-async (5)
- # cursive (79)
- # datascript (1)
- # datomic (40)
- # duct (1)
- # emacs (7)
- # figwheel-main (2)
- # graphql (7)
- # jobs (5)
- # nyc (5)
- # off-topic (61)
- # other-languages (2)
- # parinfer (6)
- # re-frame (63)
- # reagent (131)
- # ring-swagger (6)
- # shadow-cljs (158)
- # spacemacs (14)
- # tools-deps (15)
@kenny no. but you can call clj -A:xyz -m shadow.cljs.devtools.cli compile foo
instead of shadow-cljs compile foo
but consider this https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html. it is generally not useful or required to separate source paths for CLJS.
@thheller I want to write a cljs lib that wraps an npm module (in my case js-yaml). What should be the :target
for this cljs lib? Should it be :npm-module
?
@viebel nothing. CLJS libs are uncompiled source files packaged in a jar. meaning they aren't configured at all for shadow-cljs since it has nothing to build
what about the package.json file of the lib? I will include it the jar. right?
ok. let me try it
And then in an app that consumes my cljs-yaml
lib I won't need to manually install js-yaml
. Right?
if you are consuming with shadow-cljs then js-yaml
will be installed automatically if deps.cljs
specifies it
for standard CLJS it might be more tricky and I honestly can't tell you how it works there
It's ok for me to consume with shadow-cljs
But it doesn't work either - for the moment
ā shadow-cljs-app git:(master) ā shadow-cljs compile browser
shadow-cljs - config: /mnt/c/Users/USER/prj/shadow-cljs-app/shadow-cljs.edn cli version: 2.4.22 node: v8.10.0
shadow-cljs - updating dependencies
shadow-cljs - dependencies updated
shadow-cljs - starting ...
[:browser] Compiling ...
The required JS dependency "js-yaml" is not available, it was required by "cljs_yaml/core.cljs".
Searched in:/mnt/c/Users/USER/prj/shadow-cljs-app/node_modules
You probably need to run:
npm install js-yaml
See:
it doesn't contain deps.cljs
I published it with lein deploy clojars
in the root folder
It works now
šš
@thheller shadow-cljs is adding js-yaml automatically to the package.json of my app
I am not sure this is the best option
or rather yarn
does that by default. if you remove something from package.json
it is uninstalled
What I can do in my app is never touch the dependencies in package.json by myself and only works with deps.cljs. And let shadow-cljs manage the dependencies in package.json
you are going to run into conflicts eventually and gonna need npm
to resolve them anyways
I hate npm
too but thats the way it works in the JS world. can't do anything to change that.
I don't understand. What is the best place to declare my npm dependencies? package.json or deps.cljs?
Hm, I understood that @viebel is trying to make a lib for all the npm deps, and then just mark them as clj deps, letting the build tool then download the subnpmdeps. But that's discouraged?
@thheller Does shadow have some kind of concise document on how it works, internally? I often have the feeling that I need to know how the tools I use to not get cut in edge cases. For instance, I was wondering why my .-js-property accesses didn't get mangled by advanced closure, when using plain npm requires. The libraries themselves are not build with advanced, so the names stay correct on that end, but my cljs code should be.
@tomi.hukkalainen_slac since shadow-cljs processes all the JS it also extracts all properties found in those JS files and uses those for externs inference
also when using (:require ["thing" :as t])
all accesses to t/foo
are automatically added to externs
this is probably the most concise document about how it works currently https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-not-webpack.html
In this case it was callback code, again. So I'm making a function that I give to a JS thingy. Then the thingy calls my function, giving it an #js object as parameter. Then I do property access on that object
Before, on vanilla cljs (though not on the newest version) I tried to make externs for that, but ended up with metadata helpers everywhere, and eventually just used oops
when it doubt add ^js
typehints https://shadow-cljs.github.io/docs/UsersGuide.html#infer-externs
Though perhaps that's just the new and improved externs inference working better... which means I don't know how the plain cljs works either (and certainly I don't)
for example when it finds exports.foo = ...
it will add foo
to externs just in case you call it
Concretely, I was testing https://github.com/paypal/downshift#usage.
It uses the child function / render prop paradigm, so everything you do with it is always making a function that downshift will then call when it needs to, and then you work on the parameter object
It's not a full example (missing the reagent atom setup and reset function), but shows how to change the input element functionality inside the downshift autocomplete component.
yeah since JS allows setting any arbitrary props. it just won't have any effect š
Anyway, I'm miffed when things don't work as I expected, even if the work unexpectedly š
infer-externs doesn't give any warnings. I kinda would like to try if the same works on new clojurescript, but I'm guessing I couldn't get the deps installed š
I now have a fully working minimal set with lein, ring/jetty, uberjars etc. Time to move the real project into shadow
not really sure to be honest. š I am deploying my test-app to google-appengine, and that's the format there.
Added lein-tools-deps to my project, seems to work for development but the uberwar seems to compile multiple times the same file, and when I run it I get some strange errors.
Looks like a jar with a specific fs layout, shouldn't be too difficult to get working with pack, I'm a little worried about git dependencies, that might need some testing.
I have only used uberwar in appengine context. The simplest way to test the war I can think of is : https://gist.github.com/claudiuapetrei/540c8aca1ef53d86f75f123b319a3703
I mean lein makes shadow compile the cljs into resources, and then bundles the jetty server that servers that along with the dynamic api code
I was thinking if I should make this into a tutorial repository, but not sure if there's demand/use for it.
Building the thing commit by commit, where you could follow the workflow, and document the cli commands into the readme
sounds like a good idea. I still need to document the whole "migrating from X ..." parts but since I have never used X thats pretty tough
@thheller A lot of thanks for the hint from yesterday about the reload/history initialisation!
Hm. If I make a clojurescript library and use the :require :default syntax, will vanilla cljs users have problems importing my lib?
Is there any particular reasons for using lists in the table at https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages?
I had to scratch my head for a minute since before that page I've seen lists in :refer
only in really old code - now all examples use vectors.
Clojure doesnāt care if you use a list or a vector, itās just become idiomatic to use a vector. I donāt want to speak for him, but I suspect that @thheller might be using a list to help show that itās a JS dependency being brought in (same reasoning behind strings vs symbols in require)
On my real project I'm getting a bunch of
Jul 19, 2018 3:32:07 PM shadow.build.classpath invoke
WARNING: provide conflict for #{cljs_time.format cljs-time.format} provided by cljs_test/generated_test_suite.out/cljs_time/format.js and {"/cljs_time/format.cljs" #{cljs-time.format}}
Jul 19, 2018 3:32:07 PM shadow.build.classpath invoke
WARNING: provide conflict for #{cljs_time.predicates cljs-time.predicates} provided by cljs_test/generated_test_suite.out/cljs_time/predicates.js and {"/cljs_time/predicates.cljs" #{cljs-time.predicates}}
Jul 19, 2018 3:32:07 PM shadow.build.classpath invoke
INFO: filename violation for ns cljs.nodejs, got: cljs_test/generated_test_suite.out/cljs/nodejs.cljs expected: cljs/nodejs.cljs (or .cljc)
I've no idea what that generated_test_suite is, and I'm not using cljs-test myself. I tried googling and seems to point at boot-cljs-test... which is really odd. Any idea what's going on?Hm. The compiled js dir has cljs_test.generated_test_suite.out.cljs.core.constants.js
and cljs_test.generated_test_suite.out.cljs_time.internal.core.js
Well, got that fixed by upgrading the cljs-time package. New one doesn't have the conflicting files. But I wonder why lein-cljsbuild never complained about that
We just upgraded from shadow-cljs 2.4.7
to 2.4.22
and now it breaks on release with: ["scroll-into-view-if-needed" :default scroll-into-view-if-needed]
it creates P4a["default"]
but P4a
contains:
Ę (a,b){if(b===Object(b)&&0!==Object.keys(b).length&&
"function"===typeof b.behavior)return b.behavior((0,e.default)(a,b));b=!1===b?{block:"end",inline:"nearest"}:b===Object(b)&&0!==Object.keys(b).lengā¦
@mitchelkuijpers odd. did you upgrade whatever npm package that is as well? maybe they changed the export?
The problem was that our build server had npm install --no-package-lock
but that did not only not create a new package-lock.json
but it would also ignore it... Now we updated node and changed the command to npm ci
and life is great again ^^
@p-himik I always use lists for :refer
. personal preference I guess. CLJ(S) don't care, both are equally valid
@tomi.hukkalainen_slac that looks like some generated code is on the classpath, try shadow-cljs clj-repl
and then (
@thheller It was, yes, and was fixed in a new release of the lib. But I was surprised that the old cljsbuild based system didn't tell me about that
Is shadow using the clojurescript compiler, or is it completely separate and the common point is the closure compiler?
@tomi.hukkalainen_slac shadow-cljs indexes the classpath and is a bit overeager in some cases. its is the standard clojurescript compiler but the way things are resolved is a bit different, to make the custom JS resolvers possible etc.
Would be great to read a guide that opens the hood and shows different parts of the engine
yeah it takes forever to write and I never know where to start. I tried starting a blog series about the differences https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html
I suppose it is quite difficult to convert those into distinct users, as someone might be using a cached version for a year, never updating, and someone else might have a clean CI build after every line (committed separately)
yeah I don't care much about those numbers. new people keep ending up here and thats a good enough metric for me.
Ugh. The experience of starting a dev mode with material-ui is... bad. It's downloading many small files, so it takes over a minute to get all of those
I'm afraid it's also a transient dependency, so there's not much I can do from within my own code
And it looks like leaflet is somehow broken š The map tiles are really wonky. No errors, though
Might have to try to make a minimal example without any plugins, since the project uses several and the new imports might play havoc
Leaflet and its plugins are far from the best behaving modules in npm, instead relying on global vars even though they export themselves in name
Before I was just loading the dist files in the meta section, and then referring them via js/L
I didn't count, but there are hundreds, if not thousands of tiny files inside material-ui
Is there a workaround? Perhaps refer directly to the dist file, if the npm lib has that?
https://github.com/joshwcomeau/guppy/blob/master/src/components/AddDependencySearchBox/index.js
yeah you can load the dist file directly but that includes everything again. you really want to only include the components you actually use
Seems like the @material-ui/icons has so many files that unpkg times out showing the contents >_<
I know I do, and I'll try tomorrow if it makes a difference. I'm hoping my fingers crossed that the other packages I'd like to use don't just import the whole iconry wholesale
if you can only (:require ["@material-ui/icons/Add" ...])
instead of @material-ui/icons
and then icons/Add
if you include the icons index it'll pull in every single icon and not a single one will be removed by DCE
And if they did bundle them into bigger files, I suppose it would be even harder to use just a few
hello folks, is there a switch or a closure define to detect if I am in watch/repl mode in shadow?
I want to avoid executing the -main
with target :node-script
which happens when I watch
and then launch node my-script
The problem was that our build server had npm install --no-package-lock
but that did not only not create a new package-lock.json
but it would also ignore it... Now we updated node and changed the command to npm ci
and life is great again ^^