Fork me on GitHub

no, not supported.


Config can be overridden though


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


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?


@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


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.


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


and anyone trying to help debug problems


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


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


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


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


so I'm gonna say no here too


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


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?


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


although I do not recommend doing so, it is possible


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


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


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


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


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


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


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


@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


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?


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


@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.


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


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


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


@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


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 🙂


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


I mean how else do you add CLJS dependencies?


@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?


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


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)


can't add runtime dependencies view config-merge


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


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


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

👍 1

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 😄


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


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


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

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.


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


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


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


that'll make most of the required config even shorter


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


that would be cool!


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


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


just declare some metadata on a regular defn and have some other place to collect them all


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


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


keeping code stuff in code and out of config


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


not global no. this is a macro that collects them all and registers them with rt-ref


similar thing for the backend generating a reitit router table out of


metadata is underused for framework type stuff 😛


also as far as this discussion is concerned. don't forget that shadow-cljs can run any clojure code for you.


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


eg. your own browser-repl 😉

😁 1

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 😛


for a library project


> 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


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


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


> 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


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


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


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


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


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


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


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?


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


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.


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