Fork me on GitHub
#shadow-cljs
<
2022-04-18
>
thheller05:04:14

no, not supported.

Aron08:04:27

Config can be overridden though

victorb09:04:46

@thheller would you accept a PR adding support for it via a environment variable?

thheller09:04:44

if you explain the reasoning for that requirement? as far as I know neiter lein or deps.edn or any other tool I'm aware of supports this?

victorb09:04:28

@thheller sure. Being able to clean up root directory from any configuration files would be the first point. Secondly would be to be able to offer a zero-config quickstart template for users who don't necessarily care about the details of the build system. Think create-react-app but with shadow-cljs. I took a quick look at the shadow-cljs codebase and seems I could implement the feature with relatively little change to existing code, so impact wouldn't be too big. I'm unsure if lein or clojure-deps support this, although I think both can read config from stdin so indirectly they would support this (but I might remember wrong). I know for sure a bunch of JS tooling do allow this, most famous example would be webpack I guess

victorb09:04:07

clojure-deps allows setting the full (deps.edn) config via the cli arguments for example, you can run it without any files on disk (so indirectly, can load deps.edn from anywhere as well). shadow-cljs almost have this already with the config-merge argument, but that option only works if you have a file on disk already. If you have nothing, shadow-cljs exits as there is no "root" shadow-cljs.edn file to merge into.

thheller09:04:21

the reason I generally say no to this is simply because it makes my life harder

thheller09:04:31

and anyone trying to help debug problems

thheller09:04:57

right now when someone has any kind of trouble I have to ask if they are using shadow-cljs.edn only or together with project.clj/deps.edn

thheller09:04:21

if you add another mechanism where stuff might be that adds another question

thheller09:04:39

that is also the reason I was strongly against lein-shadow from the start

thheller09:04:00

suddenly you make all the documentation not apply for that user and everything has to be qualified and limited

thheller09:04:40

so I'm gonna say no here too

thheller09:04:33

also I'd argue having to set a environment variable first before you can run your program also kinda negates all possible benefit

thheller09:04:08

since you have to have some kind of dynamic management for this as well, otherwise what happens if you have 2 projects using shadow-cljs.edn. one regular. one with custom path?

thheller09:04:38

note that you can drive shadow-cljs completely without a config file

thheller09:04:49

although I do not recommend doing so, it is possible

thheller09:04:05

just as a reference: the question if deps.edn or project.clj is the most common question I have to ask and the most common source of problem for any kind of dependency related issues as well

thheller09:04:17

so I'm not talking about a once a year kinda thing

victorb09:04:53

I think it'd be fair to assume 99% of everyone would just use default settings (shadow-cljs.edn in root directory) and it would be unnecessary to ask. But, I absolutely hear your points in general and it does make sense. Reason for having the feature would not be to ask people to add the environment variable, but I want to provide a npm package that ships with a shadow-cljs config + npm script so users could run npx whatever-build-cmd without any shadow-cljs config and that build command can set the environment variable to point shadow-cljs to ./node_modules/whatever-npm-package/shadow-cljs.edn . But again, definitively hear your arguments against it, I don't want to add any more maintainer burden to you

Aron10:04:53

so, how would this work? wrap a live java dev env inside a node dev env seamlessly?

victorb10:04:08

no, npm scripts can be whatever, as long as it's executable. Right now I'm using a bash script that calls SHADOW_CLJS_CONFIG=../path/to/config.edn npx shadow-cljs release build-id so users install my npm package, then run npx whatever-build-cmd which transparently calls the right shadow-cljs commands

Aron11:04:36

I am sorry, still very confused, if you are calling shadow-cljs commands, aren't you using a jvm dev env? shadow-cljs needs the jvm afaik

thheller11:04:01

yeah, shadow-cljs is implemented in CLJ. so a JVM is required.

victorb12:04:14

@U0VQ4N5EE yeah, a JVM is used of course, but I'm not starting shadow-cljs differently than just using shadow-cljs like you normally do

Aron12:04:07

What I am confused about is that a dependency relies on a dev environment. If I install a node package, I don't expect to have to rely on the jvm also. I know some npm packages do this, so it's not unheard of, but always seemed to cause more issues when trying to use the package in another distribution, now I rely on someone else installing shadow-cljs just so they can use my package that uses your package?

Aron12:04:30

I am still half convinced I got it wrong, pls do correct me in that case.

victorb12:04:54

@U0VQ4N5EE no one will "use my package" and ship their own library based on it. I'm basically building a installable development environment for users to build figma plugins.

victorb12:04:40

just like shadow-cljs has a installable npm cli command that you can run via npm, my "build tool" will have a installable cli command that you can install and run via npm. That anything using ClojureScript comes with the runtime requirement of a JVM shouldn't be a surprise to anyone

thheller12:04:11

@UEJ5FMR6K note that it might be more relevant to create a custom :target instead of a whole build tool

thheller12:04:43

I mean just leave shadow-cljs.edn as it is and in the build config create the absolute minimum you need to build your tool. could just wrap the :browser target with some defaults

victorb12:04:55

@thheller I'm aiming to ship a "zero-config" build tool, and I'm not seeing how providing a custom :target can enable me to offer that, users would have to add a shadow-cljs.edn to their project in that case

victorb12:04:32

I'm just hacking around trying to find the right way of building all of this, so nothing is written in stone obviously, I'm happy to receive any ideas on how to make it simpler 🙂

thheller12:04:34

zero config is a pipe dream. there is no such thing as zero config. it doesn't exist. at some point you WILL require a config

thheller12:04:42

I mean how else do you add CLJS dependencies?

Aron12:04:16

@UEJ5FMR6K you did say your users will use your package and I couldn't imagine why your users need to have have this complicated way of getting shadow-cljs pre-bundled for them, why not just distribute a config file?

thheller12:04:18

the shadow-cljs.edn config is already the bare minimum, you can possibly make the build config smaller by making something figma specific

victorb12:04:58

yeah, I mean the experience of it. Obviously if people want a more customized setup they are welcome to do just that by setting up their own configuration, overwriting the one provided. But it would work for basic use cases. The config-merge option helps users to add specific parts if they want to (like additional runtime dependencies)

thheller12:04:26

can't add runtime dependencies view config-merge

victorb12:04:27

@U0VQ4N5EE people would be able to use their own config if they want to. Out-of-the-box experience won't require it though

victorb12:04:43

@thheller ah, I see, then I'll find another way 🙂

victorb12:04:34

I'm happy to share my approach to the whole thing when it's published and usable

👍 1
Aron12:04:49

good luck, not saying I would do the same way, but all the more I wish that you succeed. I just hope it's not going to be something like cra 😄

victorb12:04:54

@U0VQ4N5EE not a problem, we're lucky not everyone implements things the same way, would be a boring (and probably inefficient) world then 🙂

victorb12:04:22

@U0VQ4N5EE just for curiosity's sake, what problems do you see with the create-react-app approach?

Aron13:04:29

I don't think I can say anything new about the matter. Maybe most of the reasons are just all the hours spent on IRC helping people who followed some tutorial with cra and then ended up installing bunch of stuff they didn't need. But much more generally, I see tools that are good abstractions, you use them, and you forget about them... these don't get too popular ever, because you don't see them popping up in search results or on stackoverflow, because people don't talk about them, because these are good tools and you read the docs and don't need to write a blogpost about doing something trivial .... and then there are tools where anything simple is so overcomplicated that you are dancing between several compilers and plugins and hoping that you have used the transforms in the right order.

🙏 1
lilactown16:04:17

the problem I've seen with CRA is that it doesn't compose well. so you end up with continual creep of features, plugins, etc. that people want "zero-config" for and the alternative is to tell them to eject, which means that the user goes from "zero config that I haven't had to learn" to learning how to configure webpack/babel/etc.

lilactown16:04:27

i think if your problem is well scoped, it can work. but trying to ship a zero config solution for all web dev is a pipe dream, as thheller said

lilactown17:04:32

I'm slightly bullish on things like config generators a la phoenix, that allow you to have explicit config so you can observe what it is and tweak it without a huge wall between you and the tools, but make things easier for the usual cases

thheller17:04:07

my next goal is to actually use metadata in clojure and the power it brings

thheller17:04:19

that'll make most of the required config even shorter

thheller17:04:45

similar to the ^:dev/after-load stuff moving the "config" closer to the actual code

lilactown17:04:07

that would be cool!

thheller17:04:28

just need to figure out how to do it properly in CLJS given the macro requirement. totally easy in CLJ.

thheller17:04:05

already did some of it for my UI thing and I like it quite a bit

thheller17:04:36

just declare some metadata on a regular defn and have some other place to collect them all https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/ui/db/generic.cljs#L11

thheller17:04:04

basically this equates to re-frame (reg-event ::m/init! (fn ...))

thheller17:04:33

later then could use the same metadata to generate documentation and stuff

thheller17:04:00

keeping code stuff in code and out of config

lilactown17:04:40

so ::ev/handle would implicitly register itself with some global registry?

thheller17:04:31

not global no. this is a macro that collects them all and registers them with rt-ref https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/ui/main.cljs#L149

thheller17:04:15

similar thing for the backend generating a reitit router table out of https://github.com/thheller/shadow-experiments/blob/master/src/dev/dummy/website.clj#L12

thheller17:04:02

metadata is underused for framework type stuff 😛

thheller17:04:38

also as far as this discussion is concerned. don't forget that shadow-cljs can run any clojure code for you. https://shadow-cljs.github.io/docs/UsersGuide.html#clj-run

thheller17:04:02

so if you just make a function that tells shadow-cljs what to do that might solve all your issues you might have with a build config

thheller17:04:13

eg. your own browser-repl 😉

😁 1
lilactown17:04:56

the browser-repl ask in the channel was just me being lazy and not wanting to copy + paste the same index.html and build config i carry around with me 😛

lilactown17:04:06

for a library project

victorb09:04:30

> note that you can drive shadow-cljs completely without a config file How would one go about to do this? I tried looking at the "library" usage instead of cli usage of shadow-cljs but I didn't find any documentation about it so not sure if it was possible or not

thheller09:04:13

well driving a build you can do entirely without any config via the CLJ api

thheller09:04:37

if you need something to start the actual JVM without any other tool then you kinda need the config to declare dependencies and so on

victorb09:04:53

> although I do not recommend doing so, it is possible Because of churn in the API interface or for some other reason? I'm thinking if it's easier for me to just maintain my own shadow-cljs fork at that point rather than using the library, since adding support for loading config from env var would just be ~5 lines of code

victorb09:04:28

> well driving a build you can do entirely without any config via the CLJ api Right, I'll take a look at that. Thanks!

thheller09:04:48

shadow.cljs.devtools.api/release or compile or watch all take a build-id argument

thheller09:04:57

which can just take a map defining the build directly, so it won't look it up in the config instead

victorb09:04:03

ah, that should be good enough for what I'm doing. Thanks a lot for taking the time to explain and help out 🙂

thheller10:04:32

the reason the config should generally have the build config is because some features are tied to it. (eg. the UI)

thheller10:04:14

also easier to debug if something doesn't work as expected. eg. a user build failing because of an error. if there is no visible build config that is much harder to debug

isak16:04:11

In the build report, for the "Generated Files" section, I think it would be helpful to extract everything that starts with "node_modules/" to be top level entries (grouped by package or folder) similar to how CLJS dependencies like reagent would appear. Thoughts?

thheller16:04:37

@isak upgrade shadow-cljs. that was a bug for a couple versions

zhuxun221:04:25

Is there a way to retrieve the entry point of a compiled web worker based on its module key? Currently, I have to do (js/Worker. "/...<path-to-web-worker>.js"). Sometimes I changed the assay path and forgot to update this line as well.

zhuxun222:04:45

Another question: Is goog.DEBUG the best way to separate the dev build from release build? Will it be compiled away?