Maybe I am also just questioning this since my nvim setup doesn't allow me to jump to the task definition in the bb.edn file for the external tasks 😅 Makes it less transparent..

I don't have numbers on this of course, but I'm guessing that a good chunk of biff users are actually fine without customizing the deployment tasks. since biff targets solo developers, presumably there are fewer constraints around needing to deploy on your org's existing infra. I can at least say that I haven't needed to use per-project deploy tasks for my own projects. and if you do, you can always copy the source into your tasks.clj file and edit from there (or write new tasks from scratch, depending on how much your needs differ from what's provided.) a benefit of keeping implementations in the library is that I can update them and let people upgrade existing projects by just bumping the biff version.

This made me think of the https://biffweb.com/docs/reference/architecture/: > Biff has two parts: a library and a template project. As much code as possible is written as library code, exposed under the com.biffweb namespace. Going by this principle, it makes sense to keep as much code in the external tasks library as possible. @U8ZN5EHGU: > Maybe I am also just questioning this since my nvim setup doesn't allow me to jump to the task definition in the bb.edn file for the external tasks 😅 I feel your pain here. It doesn't work in Cursive either, likely because bb.edn is a Babashka-specific thing and tooling is still catching up. I might end up filing a bug report in Cursive for this, at least so it's documented as an issue. Might be worth doing the same for the vim plugin

Thanks for explaining! I makes sense if it fits the majority of use cases 🙂