00:00 Introduction 04:36 Creating empty deps.edn and bb.edn 06:26 Creating bin/launchpad 07:41 Making babashka (bb.edn) aware of launchpad 07:59 First successful execution 08:25 Manually connecting from editor to running n-repl 09:52 Why use cider-jack-in 10:30 bin/launchpad --emacs (alias for cider-nrepl, refactor-nrepl middlewares) 11:24 Explanation of the necessity of local bin/launchpad 13:27 Deps Reloading concept 15:35 deps.local.edn concept (not version controlled local deps.edn that overrides deps.edn) 18:36 .env reloading 21:51 passing aliases from command line as launchpad ALIAS 22:49 configuring launchpad on deps.local.edn with :launchpad/(options, aliases, main-opts, shadow-build-ids) 23:24 :launchpad/main-opts and :launchpad/options 27:52 watchers 31:16 monorepo 36:26 multiple repos loaded on one proccess warning/advice 37:26 go flag 38:44 launchpad with pnpm-install custom script 39:02 launchpad with wait-for-mysql custom script 42:43 README 43:20 :pre-steps 44:57 scattered repositories
Really nice. In case it's helpful to someone, the linking of :local/root code that exists outside the project to the existing REPL 17:40 invoked sesman-link-with-least-specific - love how dynamic this makes investigating potential bugs in dependencies (or - more likely - misuse of them) 👏
Arne, this looks like a very useful tool. My own workflow has about 80% of what is in here, but it is bespoke and a manual setup for every new project. This looks like a much easier way to get a new project up and running in a consistent and predictable manner where there is less likelihood of steps being missed or being different enough to cause confusion or additional cognitive load when switching projects. As you point out, also great for getting a team all working in a consistent configuration. ONe suggestion I do have is perhaps it would be worthwhile creating a wiki or similar where diffeent configuration recopies could be shared? I find people often get a little choice paralysis due to the flexibility available in the clj ecosystem. A few examples can either provide increased confidence your on the right track or help narrow down options when your overloaded etc. This could also be projection and just something I suffer from! Either way, about to look at adoptiong this tool for my own projects. Thank you.
00:00 Introduction
04:36 Creating empty deps.edn and bb.edn
06:26 Creating bin/launchpad
07:41 Making babashka (bb.edn) aware of launchpad
07:59 First successful execution
08:25 Manually connecting from editor to running n-repl
09:52 Why use cider-jack-in
10:30 bin/launchpad --emacs (alias for cider-nrepl, refactor-nrepl middlewares)
11:24 Explanation of the necessity of local bin/launchpad
13:27 Deps Reloading concept
15:35 deps.local.edn concept (not version controlled local deps.edn that overrides deps.edn)
18:36 .env reloading
21:51 passing aliases from command line as launchpad ALIAS
22:49 configuring launchpad on deps.local.edn with :launchpad/(options, aliases, main-opts, shadow-build-ids)
23:24 :launchpad/main-opts and :launchpad/options
27:52 watchers
31:16 monorepo
36:26 multiple repos loaded on one proccess warning/advice
37:26 go flag
38:44 launchpad with pnpm-install custom script
39:02 launchpad with wait-for-mysql custom script
42:43 README
43:20 :pre-steps
44:57 scattered repositories
Really nice. In case it's helpful to someone, the linking of :local/root code that exists outside the project to the existing REPL 17:40 invoked sesman-link-with-least-specific - love how dynamic this makes investigating potential bugs in dependencies (or - more likely - misuse of them) 👏
Wow looks like this would fix most of the usability issues I've experienced with the default clojure tooling. Great work!
Arne, this looks like a very useful tool. My own workflow has about 80% of what is in here, but it is bespoke and a manual setup for every new project. This looks like a much easier way to get a new project up and running in a consistent and predictable manner where there is less likelihood of steps being missed or being different enough to cause confusion or additional cognitive load when switching projects. As you point out, also great for getting a team all working in a consistent configuration. ONe suggestion I do have is perhaps it would be worthwhile creating a wiki or similar where diffeent configuration recopies could be shared? I find people often get a little choice paralysis due to the flexibility available in the clj ecosystem. A few examples can either provide increased confidence your on the right track or help narrow down options when your overloaded etc. This could also be projection and just something I suffer from! Either way, about to look at adoptiong this tool for my own projects. Thank you.
Great suggestion!
ah not sure if there was either a recording or video rendering issue but the audio is very very quiet
the tool is really cool, but this video is extremely quiet