This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (39)
- # babashka-sci-dev (59)
- # beginners (60)
- # calva (14)
- # circleci (1)
- # clj-kondo (16)
- # clj-on-windows (1)
- # clojure (95)
- # clojure-europe (5)
- # clojure-norway (2)
- # clojurescript (34)
- # conjure (2)
- # core-async (55)
- # datomic (4)
- # emacs (54)
- # holy-lambda (5)
- # hyperfiddle (2)
- # interop (4)
- # lsp (8)
- # malli (3)
- # nrepl (4)
- # off-topic (34)
- # polylith (5)
- # reitit (3)
- # releases (2)
- # shadow-cljs (85)
- # specter (2)
- # testing (8)
- # tools-deps (12)
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.
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
suddenly you make all the documentation not apply for that user and everything has to be qualified and limited
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?
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
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
@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?
@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
@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?
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)
@U0VQ4N5EE people would be able to use their own config if they want to. Out-of-the-box experience won't require it though
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.
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
just need to figure out how to do it properly in CLJS given the macro requirement. totally easy in CLJ.
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
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
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
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
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
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 😛
> 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
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!
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
so, how would this work? wrap a live java dev env inside a node dev env seamlessly?
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?
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.