https://commandbox.ortusbooks.com/task-runners/loading-ad-hoc-modules

As a first go at this, I've added a new loadModule() method to the base task runner. Any task CFC can load ad-hoc modules from a relative or absolute directory at runtime and use them immediately.

I was thinking on this last night. What if the require or loadmodule method (whatever we call it) was also smart enough to go and fetch the modules from ForgeBox if they weren't already there locally? We'd need some convention for where they should be put, but since this is all running inside of CommandBox, it knows how to get stuff.

I've been thinking about how task runners can be as portable as possible without the need for any additional `box install` sort of steps to be able to use them. If a task declares that it can't run without module "foobar" installed, and it's not loaded yet, then the CLI could just grab it off Forgebox right then, install it to a temp folder or convention location, and load it on the fly. The next time the task runner was executed on that machine, it would already be ready to go.

I want someone to be able to have a project with a task runner build that requires additional 3rd party modules or perhaps some custom buildpacks they've made, and for anyone to easily run that task without needing to permanently add anything into their local CommandBox install. Sort of a combination of Ant's

and

Thoughts?

Thanks for the additional thoughts . It's worth noting that there's no requirement to physically copy the module anywhere as the module service can actually just load a module into memory from any ad hoc directory. if you check the CommandBox mailing list, I actually just showed someone the code to do this today. It's literally two lines of code and it leaves all the module's files right where they are.

I think it highlights the difference I just learned between preProcess and preEvent in ColdBox. Maybe we need to add a few new interceptors, something like preInvoke and postInvoke, to capture that point in the lifecycle.

As far as unloading, I had two thoughts. One, these load( "module" ) calls should load the module to a temporary folder, one that we know will be unloaded on each postInvoke. That being said, we could still check if the module was registered in the ModuleService before loading it initially Then, when we unload modules, we only unload those in our temporary folder.