Fork me on GitHub
#shadow-cljs
<
2018-08-24
>
richiardiandrea00:08:34

are lifecycle hooks working for node targets: I am trying to use :after-load but it does not seem to get triggered

richiardiandrea00:08:26

nvm it works, I just did not see that print in the node process terminal

kwladyka10:08:20

I will present me team shadow-cljs as alternative to leiningen. Maybe we could use it instead. Can you recommend articles about lein <-> shadow-cljs code compatibility, something what prove shadow-cljs is mature solution and no scary to use it etc.?

thheller10:08:56

if your team is used to leiningen then there is no reason to switch

thheller10:08:54

I assume you mean switch from cljsbuild/figwheel though and no I haven't written anything on that subject yet

thheller10:08:20

I started several times but its tough for me to write it since I haven't used cljsbuild/figwheel for 4+ years

thheller10:08:48

does me using it in production for 4 years count as mature? 😛

kwladyka10:08:57

sure, but team probably want something more black and white prove on paper

kwladyka10:08:58

I think the main difference is how :require macros looks. Also in shadow we can write event.target.name while in lein we can not (as i know)

thheller10:08:17

nope all that is completely standard

thheller10:08:55

shadow-cljs just uses the normal CLJS compiler. the only modification it does is basically to the parsing of the ns form. thats it.

thheller10:08:10

everything else is completely standard

thheller10:08:30

well I guess npm support isn't standard

kwladyka10:08:31

but the same :require code wouldn’t work with lein

thheller10:08:49

depends on what you require but otherwise it should behave exactly the same

kwladyka10:08:13

I want to point what is not compatible

thheller10:08:26

JS deps aren't compatible

thheller10:08:29

everything else is

kwladyka10:08:33

This is the main concern of people

kwladyka10:08:55

ok so by deps we mean exactly this :require code part?

thheller10:08:19

CLJS/lein cannot do (:require ["some-npm-dep" :as x]) reliably

thheller10:08:26

so those JS deps will not work

thheller10:08:44

(:require [any.other.cljs.ns :as x]) will work just fine

thheller10:08:30

CLJSJS deps don't work which is the big adjustments your team would need to make

kwladyka18:08:39

Because of deps.edn. How to determine which CLJSJS will / wouldn’t work?

thheller20:08:32

none will work but you can "emulate" them. some are already emulated. https://github.com/thheller/shadow-cljsjs/tree/master/src/main

thheller10:08:41

ie. switch from using CLJSJS deps to using npm directly instead

kwladyka10:08:26

any other hints what talk to people to introduce shadow-cljs?

kwladyka10:08:04

BTW Why somebody could prefer https://shadow-cljs.github.io/docs/UsersGuide.html#Leiningen instead of use shadow-cljs directly?

thheller10:08:12

if you have a Clojure server-side using lein

kwladyka10:08:30

What do you mean?

thheller10:08:12

the only focus of shadow-cljs is CLJS development. if you do any kind of CLJ development I recommend using lein for that part.

thheller10:08:40

some people prefer running only one tool and embedded shadow-cljs in their CLJ server process instead

kwladyka10:08:49

so for projects which contains clj and cljs files in the same project / repository ?

thheller10:08:13

if you do any kind of CLJ development yes. the presence of .clj files could just be macros or utility functions, those are fine for shadow-cljs

thheller10:08:03

some people also use deps.edn instead of lein

thheller10:08:17

its all fine and I guess depends on how much non-CLJS development you do

thheller10:08:41

some also use deps.edn for pure CLJS development though due to the extra features deps.edn offer (eg. git-deps)

kwladyka10:08:44

BTW something moved forward with lein cljs npm dependency support?

thheller10:08:05

remove the "lein" modifier from your statements

thheller10:08:14

"lein" has absolutely nothing to do with any of this

thheller10:08:44

standard clojurescript has the limitations, not lein. and no it is still a work-in-progress with many rough edges.

thheller10:08:43

shadow-cljs basically uses the standard clojurescript compiler but replaces the JS support with its own implementation. thats it.

thheller10:08:55

all other tools use the standard implementation which is a bit unreliable

thheller10:08:19

those might be helpful. good experience reports in trying to get JS deps working.

kwladyka10:08:09

thank you, I will look on it. Now I have to go and will be back in a few hours.

kwladyka19:08:28

Hmm so while you could rewrite this limitations in shadow-cljs, why standard cljs can’t?

wilkerlucio19:08:29

standard cljs is targetting a harder integration, they want to make so every node module is correctly understood by Google Closure so they can be optimized on release builds. As far as I understand, Shadow relaxes on this goal and just copy over the used files (grossly speaking), this doesn't have all the good optimizations, but works

thheller19:08:38

the JS integration in shadow-cljs is basically modeled after webpack instead and following their conventions.

kwladyka19:08:06

So shorty this is about what @U066U8JQJ said?

thheller19:08:28

its really not that easy to explain the differences

thheller19:08:45

shadow-cljs sacrifices some optimizations for better compatibility with JS

thheller19:08:15

clojurescript doesn't do that and the end result is better when it works.

trollface 4
thheller19:08:23

it however rarely works.

thheller19:08:53

the difference is only in the JS integration. the generated CLJS code is identical.

dnolen20:08:35

but note all that old stuff is really obviated by the new Webpack support

dnolen20:08:42

linking to that stuff now doesn’t make any sense to me

dnolen20:08:57

we’ve more or less stopped recommending :npm-deps as the way since the last release

richiardiandrea20:08:11

@dnolen say I am producing a ClojureScript library which has npm dependencies, does the Webpack method would work there? seems like I would still need to declare transitive :npm-deps somehow

dnolen20:08:50

Webpack support has nothing to do with :npm-deps

dnolen20:08:07

there’s really no point in talking about them together

dnolen20:08:45

as in - they will never interoperate - but this not really important for the common use case of - I just need X from node_modules for this thing I’m trying to ship

dnolen21:08:05

most of teeth gnashing in the past is about that - not what you’re talking about

richiardiandrea21:08:03

right, so the webpack solution is only for compiling down in order to produce either a node script or a browser JS - make sense, thank you!

urbanslug21:08:17

So mainly based on https://github.com/thheller/shadow-cljs/issues/179#issue-289518679 I'm trying to come up with devcards template for shadow-cljs https://gitlab.com/urbanslug/sniff/blob/master/shadow-cljs.edn However, when I run yarn devcards I get the error that the build for app isn't running and well devcards doesn't work. Anyone have an idea about this?

thheller21:08:05

> I get the error that the build for app isn't running

thheller21:08:24

what kind of error is that? I don't know of any such error in shadow-cljs

thheller21:08:24

devcards doesn't work how? I don't see it in dependencies?