Given the way the HE platform works today, your proposal does not enable modularity and code reuse that cannot exist otherwise, it only enables it in a specific way, by assembling the final Groovy script at byte-compile time, directly on the hub.
Beyond the dependency issues that were brought up by @csteele and which will inevitably arise, doing things this way also has the downside of making line numbers that appear in run-time exceptions nearly unusable. Friction for the users.
Having the developer assemble the script code upstream - prior to the user uploading the result to the hub as a monolithic driver or app script - enables the same modularity and reuse goals, but it does potentially add developer-side friction.
Respectfully disagree.
Hubitat thinks exactly this. You've been around here for 6 years, I have to imagine you've read enough Topics to detect this. Take HPM as just one example, for all the years you've been here, people suggesting that HPM be integrated into the platform is a near constant. 3-4 times a year, I'd predict.
No matter how popular we the Community imagines ourselves to be, Hubitat can't exist on just us. There MUST be a 10x to 50x population of hub owners that never join or visit. Community code, as amazing as it is, really... just is not a big part of Hubitat's business, I hope 
It's a part, an important part, just not a big part, I am guessing. I'm no more aware of their business than you are, I think.
So, yea, I respectfully disagree too.
1 Like
I woudn't say that it wouldn't be accepted. But it may not be picked up on by many people. Again, I don't disagree with the idea of what you are asking for in concept, but it has some hurtels to overcome for wide use. Just knowing about it is one of them
2 Likes
