**Description:**
Following up https://github.com/swc-project/swc/pull/7422, `swc_core::plugin` itself is not exposed to `__plugin_transform_host`, so still not able to access the inner plugin proxy.
**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.
**Description:**
This issue is more severe than I originally thought. It raises not in
array indexing, but in function calls and property mutation. We should
treat all function arguments as potentially be property mutated,
otherwise following example
```js
class A {
a = 1
toString() {
return this.a
}
}
const a = new A()
function foo(x) {
x.a++
}
const b = a + 1
foo(a)
console.log(b)
```
would be error(It should log 2, but logs 3 after compress).
As the result, massive regressions is unavoidable, since some of these
optimizations may indeed cause error. Part of them can be mitigated with
following optimization -- allow inline of ident even if its original
value is mutated. Consider
```js
export function foo(x) {
const y = x
x.a = 1
y.b = 2
}
```
If x is a primitive value, all mutations to its properties are ignored;
if x is a object, then y refers to the same object no matter what
mutation is performed.
And there's still room for more, currently following code
```js
export function foo(x) {
const y = Math.floor(x);
g(y);
}
```
But I'd rather do it in a separate PR.
**Related issue:**
- Closes#7402.
**Description:**
I just realized there could be some case who'll want plugin in native env, but without filesystem cache. If there's a custom cache implementation, it'll make a conflict to swc's caching mechanism since swc does not expose any interface to the its cache.
PR takes simple approach to expose another feature to opt in native env with memory cache for those case. Ideally we should make `plugin_transform_host_native` to not to opt-in any cache, and then make `swc_plugin_runner` to run without any cache implementation - but that'll be a breaking changes with few more involved changes.
