@ClearScriptLib that's unfortunate. I spent a lot of time on the plugin system so far. It works great because modules can reference other modules but also have the private access. Only access exported members, import other plugins stuff they exported etc.

Please don't break backwards compatibility and mine (and who knows who else may be relying on this).

Would I be able to disable that cache system support?

Or maybe invalidate a module? (To signal it needs to be reloaded)

Please don't break backwards compatibility and mine (and who knows who else may be relying on this).

Rest assured that we strongly oppose breaking changes and try to avoid them at all costs, but sometimes we slip up, and sometimes there's nothing we can do – e.g., V8 drops support for a public API, the Windows team removes VBScript, etc.

So, first, let's make sure we're on the same page. What exactly does it mean to disable a module? You're aware that resources that have already been imported from that module cannot be yanked, right?

@ClearScriptLib I have been thinking about it, and even looking at the v8 api, and I think you're right. I might need to implement a plugins reloaded mechanism if I'm gonna stick with plugin removing/disabling. So everytime a user disables/removes a plugin the engine/context would have to be freed and plugins reloaded/executed again.