You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would love if taskfile can not only conditionally perform a task, but by telling it what it generates that it would be able to cache everything that was generated by a chechsum so it can copied over rather than re-execute.
I understand though that first #2181 needs to be addressed.
For that you should consider a cache solution. Most compiler toolchains will already support some form of caching, or you can easily create one yourself - a dep task that looks in the checksum file and, if available, downloads files from a cache (based on the checksums).
As cache strategies are going to be very domain specific I can't imagine a generic solution in Task making too much sense (please prove me wrong ....). Better just write a dep task to do whatever you need.
Take a look at the checksum files and decide if there is enough info available to implement your own cache.
I hope you don't take this in a wrong way, as my intention is being constructive. This is the third issue is a short time you replied to me with something in the like of: You can easily do X on a task Y. I don't think it's an useful comment. I know that. You can easily do a lot of what task do as well. What changes is where maintainers want to draw the line.
Having said that, I offer ideas or feature requests of things that I've already done myself in different ways. But when I find a tool that's has the potential to be ubiquitous in my dev processes and one I can recommend or enforce, and specially those that already have something built closer to it I like to verbalize it.
I now sometimes it could be scratching my own itch, but a lot of times it might be a good idea for me, the maintainer or anyone else to implement.
My use case:
A client is deploying a site with laravel forge.
Each push generates a new release and they have their own rollover process.
The theme is built on each deploy even when nothing changed.
If I can tell task to keep a cache of generated files (I am already configuring the generated files I want it to look after), maybe specified something other things like access times or expire date or anything in the like I can have this already there and ready to be used whenever I want.
Also, this particular cache strategy is not that very tied to the domain. Is a hash -> artifact cache strategy. It can be used with a lot of different domains.
Task should support everything you need to realise your use case.
If you find a limitation that prevents such a use case, then open an issue so that your use case can be enabled (or open a PR!)
However, Task is not a cache service, or a database for metadata. Task is a task runner, and you can write tasks to do those things (which will be far more effective anyway).
Activity
trulede commentedon Jun 8, 2026
For that you should consider a cache solution. Most compiler toolchains will already support some form of caching, or you can easily create one yourself - a
deptask that looks in the checksum file and, if available, downloads files from a cache (based on the checksums).As cache strategies are going to be very domain specific I can't imagine a generic solution in Task making too much sense (please prove me wrong ....). Better just write a
deptask to do whatever you need.Take a look at the checksum files and decide if there is enough info available to implement your own cache.
hanoii commentedon Jun 9, 2026
I hope you don't take this in a wrong way, as my intention is being constructive. This is the third issue is a short time you replied to me with something in the like of: You can easily do X on a task Y. I don't think it's an useful comment. I know that. You can easily do a lot of what task do as well. What changes is where maintainers want to draw the line.
Having said that, I offer ideas or feature requests of things that I've already done myself in different ways. But when I find a tool that's has the potential to be ubiquitous in my dev processes and one I can recommend or enforce, and specially those that already have something built closer to it I like to verbalize it.
I now sometimes it could be scratching my own itch, but a lot of times it might be a good idea for me, the maintainer or anyone else to implement.
My use case:
If I can tell task to keep a cache of generated files (I am already configuring the generated files I want it to look after), maybe specified something other things like access times or expire date or anything in the like I can have this already there and ready to be used whenever I want.
Also, this particular cache strategy is not that very tied to the domain. Is a hash -> artifact cache strategy. It can be used with a lot of different domains.
trulede commentedon Jun 9, 2026
Task should support everything you need to realise your use case.
If you find a limitation that prevents such a use case, then open an issue so that your use case can be enabled (or open a PR!)
However, Task is not a cache service, or a database for metadata. Task is a task runner, and you can write tasks to do those things (which will be far more effective anyway).
(I will convert this to a discussion)