OJ Kwon ac5ab607c9 refactor(plugin/runner): Revise cache, module loading (#7408) ... **Description:** One of the oversight around design of `TransformExecutor` is encapsulating plugin module logic. It has access to the cache and do its own loading & storing. This means consumer of plugin runner have tricky challenge to control its caching system. First, there is no way to escape how swc_plugin_runner controls cache and cannot synchronize into their own, also depends on the usecases cannot control the features they want to opt in: for example, there's no way one interface uses in-memory cache, and another uses filesystem since it is compile time configured singleton. PR revisits overall design of TransformExecutor: now it accepts a tratir `PluginModuleBytes`, which abstracts any kind of bytes we are dealing with, such as raw file slice or serialized `wasmer::Module`. Cache instantiation and managing is now bubbled up to the application level (`swc` in here), so if someone wants non-singleton caching or integrate into their own caching system it can be customized. Lastly, deprecated `memory_cache` feature and only exposes `filesystem_cache`. Cache implementation uses in-memory is always available, and can opt in filesystem cache where it's supported. **BREAKING CHANGE:** This is clearly breaking changes for the consumers of swc_core. for the @swc/core, this PR takes care of necessary changes. I'll work on next-swc changes later once we have new @swc/core version with this changes.		2023-05-18 07:05:39 +00:00
..
assets	chore(plugin): Add a benchmark (#4397)	2022-04-22 14:52:55 +09:00
ecma_invoke.rs	refactor(plugin/runner): Revise cache, module loading (#7408)	2023-05-18 07:05:39 +00:00