2022-09-18 12:54:06 +03:00
|
|
|
#![cfg_attr(not(feature = "__rkyv"), allow(warnings))]
|
|
|
|
use std::{
|
|
|
|
env, fs,
|
|
|
|
path::{Path, PathBuf},
|
|
|
|
process::{Command, Stdio},
|
|
|
|
sync::Arc,
|
|
|
|
};
|
|
|
|
|
|
|
|
use anyhow::{anyhow, Error};
|
|
|
|
use serde_json::json;
|
|
|
|
#[cfg(feature = "__rkyv")]
|
|
|
|
use swc_common::plugin::serialized::PluginSerializedBytes;
|
|
|
|
use swc_common::{
|
2022-09-24 06:33:47 +03:00
|
|
|
collections::AHashMap, plugin::metadata::TransformPluginMetadataContext, sync::Lazy, FileName,
|
|
|
|
Mark,
|
2022-09-18 12:54:06 +03:00
|
|
|
};
|
|
|
|
use swc_ecma_ast::{EsVersion, Program};
|
2023-03-30 11:06:02 +03:00
|
|
|
use swc_ecma_parser::{parse_file_as_program, Syntax, TsConfig};
|
2023-06-21 06:16:33 +03:00
|
|
|
use testing::CARGO_TARGET_DIR;
|
2022-09-18 12:54:06 +03:00
|
|
|
use tracing::info;
|
|
|
|
|
|
|
|
/// Returns the path to the built plugin
|
|
|
|
fn build_plugin(dir: &Path) -> Result<PathBuf, Error> {
|
|
|
|
{
|
|
|
|
let mut cmd = Command::new("cargo");
|
2023-06-21 06:16:33 +03:00
|
|
|
cmd.env("CARGO_TARGET_DIR", &*CARGO_TARGET_DIR);
|
2022-09-18 12:54:06 +03:00
|
|
|
cmd.current_dir(dir);
|
|
|
|
cmd.args(["build", "--target=wasm32-wasi", "--release"])
|
|
|
|
.stderr(Stdio::inherit());
|
|
|
|
cmd.output()?;
|
|
|
|
|
|
|
|
if !cmd
|
|
|
|
.status()
|
|
|
|
.expect("Exit code should be available")
|
|
|
|
.success()
|
|
|
|
{
|
|
|
|
return Err(anyhow!("Failed to build plugin"));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-06-21 06:16:33 +03:00
|
|
|
for entry in fs::read_dir(&CARGO_TARGET_DIR.join("wasm32-wasi").join("release"))? {
|
2022-09-18 12:54:06 +03:00
|
|
|
let entry = entry?;
|
|
|
|
|
|
|
|
let s = entry.file_name().to_string_lossy().into_owned();
|
|
|
|
if s.eq_ignore_ascii_case("swc_noop_plugin.wasm") {
|
|
|
|
return Ok(entry.path());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Err(anyhow!("Could not find built plugin"))
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(feature = "__rkyv")]
|
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 10:05:39 +03:00
|
|
|
static PLUGIN_BYTES: Lazy<swc_plugin_runner::plugin_module_bytes::CompiledPluginModuleBytes> =
|
|
|
|
Lazy::new(|| {
|
|
|
|
let path = build_plugin(
|
|
|
|
&PathBuf::from(env::var("CARGO_MANIFEST_DIR").unwrap())
|
|
|
|
.join("tests")
|
|
|
|
.join("fixture")
|
|
|
|
.join("swc_noop_plugin"),
|
|
|
|
)
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
let raw_module_bytes = std::fs::read(&path).expect("Should able to read plugin bytes");
|
|
|
|
let store = wasmer::Store::default();
|
|
|
|
let module = wasmer::Module::new(&store, raw_module_bytes).unwrap();
|
|
|
|
|
|
|
|
swc_plugin_runner::plugin_module_bytes::CompiledPluginModuleBytes::new(
|
|
|
|
path.as_os_str()
|
|
|
|
.to_str()
|
|
|
|
.expect("Should able to get path")
|
|
|
|
.to_string(),
|
|
|
|
module,
|
|
|
|
store,
|
|
|
|
)
|
|
|
|
});
|
2022-09-18 12:54:06 +03:00
|
|
|
|
|
|
|
#[cfg(feature = "__rkyv")]
|
|
|
|
#[testing::fixture("../swc_ecma_parser/tests/tsc/*.ts")]
|
|
|
|
#[testing::fixture("../swc_ecma_parser/tests/tsc/*.tsx")]
|
|
|
|
fn internal(input: PathBuf) -> Result<(), Error> {
|
|
|
|
// run single plugin
|
|
|
|
testing::run_test(false, |cm, _handler| {
|
|
|
|
let fm = cm.new_source_file(FileName::Anon, "console.log(foo)".into());
|
|
|
|
|
|
|
|
let parsed = parse_file_as_program(
|
|
|
|
&fm,
|
|
|
|
Syntax::Typescript(TsConfig {
|
|
|
|
tsx: input.to_string_lossy().ends_with(".tsx"),
|
|
|
|
..Default::default()
|
|
|
|
}),
|
|
|
|
EsVersion::latest(),
|
|
|
|
None,
|
|
|
|
&mut vec![],
|
|
|
|
)
|
|
|
|
.unwrap();
|
|
|
|
|
2023-05-15 06:17:31 +03:00
|
|
|
let program = PluginSerializedBytes::try_serialize(
|
|
|
|
&swc_common::plugin::serialized::VersionedSerializable::new(parsed.clone()),
|
|
|
|
)
|
|
|
|
.expect("Should serializable");
|
2022-09-18 12:54:06 +03:00
|
|
|
let experimental_metadata: AHashMap<String, String> = [
|
|
|
|
(
|
|
|
|
"TestExperimental".to_string(),
|
|
|
|
"ExperimentalValue".to_string(),
|
|
|
|
),
|
|
|
|
("OtherTest".to_string(), "OtherVal".to_string()),
|
|
|
|
]
|
|
|
|
.into_iter()
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
let mut plugin_transform_executor = swc_plugin_runner::create_plugin_transform_executor(
|
|
|
|
&cm,
|
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 10:05:39 +03:00
|
|
|
&Mark::new(),
|
2022-09-18 12:54:06 +03:00
|
|
|
&Arc::new(TransformPluginMetadataContext::new(
|
|
|
|
None,
|
|
|
|
"development".to_string(),
|
|
|
|
Some(experimental_metadata),
|
|
|
|
)),
|
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 10:05:39 +03:00
|
|
|
Box::new(PLUGIN_BYTES.clone()),
|
2022-09-18 12:54:06 +03:00
|
|
|
Some(json!({ "pluginConfig": "testValue" })),
|
2023-06-08 05:19:07 +03:00
|
|
|
None,
|
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 10:05:39 +03:00
|
|
|
);
|
2022-09-18 12:54:06 +03:00
|
|
|
|
|
|
|
info!("Created transform executor");
|
|
|
|
|
|
|
|
let program_bytes = plugin_transform_executor
|
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 10:05:39 +03:00
|
|
|
.transform(&program, Some(false))
|
2022-09-18 12:54:06 +03:00
|
|
|
.expect("Plugin should apply transform");
|
|
|
|
|
|
|
|
let program: Program = program_bytes
|
|
|
|
.deserialize()
|
2023-05-15 06:17:31 +03:00
|
|
|
.expect("Should able to deserialize")
|
|
|
|
.into_inner();
|
2022-09-18 12:54:06 +03:00
|
|
|
|
|
|
|
assert_eq!(parsed, program);
|
|
|
|
|
|
|
|
Ok(())
|
|
|
|
})
|
|
|
|
.expect("Should able to run single plugin transform");
|
|
|
|
|
|
|
|
// Run multiple plugins.
|
|
|
|
testing::run_test(false, |cm, _handler| {
|
|
|
|
let fm = cm.new_source_file(FileName::Anon, "console.log(foo)".into());
|
|
|
|
|
|
|
|
let parsed = parse_file_as_program(
|
|
|
|
&fm,
|
2023-03-30 11:06:02 +03:00
|
|
|
Syntax::Es(Default::default()),
|
2022-09-18 12:54:06 +03:00
|
|
|
EsVersion::latest(),
|
|
|
|
None,
|
|
|
|
&mut vec![],
|
|
|
|
)
|
|
|
|
.unwrap();
|
|
|
|
|
2023-05-15 06:17:31 +03:00
|
|
|
let mut serialized_program = PluginSerializedBytes::try_serialize(
|
|
|
|
&swc_common::plugin::serialized::VersionedSerializable::new(parsed.clone()),
|
|
|
|
)
|
|
|
|
.expect("Should serializable");
|
2022-09-18 12:54:06 +03:00
|
|
|
|
|
|
|
let experimental_metadata: AHashMap<String, String> = [
|
|
|
|
(
|
|
|
|
"TestExperimental".to_string(),
|
|
|
|
"ExperimentalValue".to_string(),
|
|
|
|
),
|
|
|
|
("OtherTest".to_string(), "OtherVal".to_string()),
|
|
|
|
]
|
|
|
|
.into_iter()
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
let mut plugin_transform_executor = swc_plugin_runner::create_plugin_transform_executor(
|
|
|
|
&cm,
|
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 10:05:39 +03:00
|
|
|
&Mark::new(),
|
2022-09-18 12:54:06 +03:00
|
|
|
&Arc::new(TransformPluginMetadataContext::new(
|
|
|
|
None,
|
|
|
|
"development".to_string(),
|
|
|
|
Some(experimental_metadata.clone()),
|
|
|
|
)),
|
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 10:05:39 +03:00
|
|
|
Box::new(PLUGIN_BYTES.clone()),
|
2022-09-18 12:54:06 +03:00
|
|
|
Some(json!({ "pluginConfig": "testValue" })),
|
2023-06-08 05:19:07 +03:00
|
|
|
None,
|
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 10:05:39 +03:00
|
|
|
);
|
2022-09-18 12:54:06 +03:00
|
|
|
|
|
|
|
serialized_program = plugin_transform_executor
|
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 10:05:39 +03:00
|
|
|
.transform(&serialized_program, Some(false))
|
2022-09-18 12:54:06 +03:00
|
|
|
.expect("Plugin should apply transform");
|
|
|
|
|
|
|
|
// TODO: we'll need to apply 2 different plugins
|
|
|
|
let mut plugin_transform_executor = swc_plugin_runner::create_plugin_transform_executor(
|
|
|
|
&cm,
|
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 10:05:39 +03:00
|
|
|
&Mark::new(),
|
2022-09-18 12:54:06 +03:00
|
|
|
&Arc::new(TransformPluginMetadataContext::new(
|
|
|
|
None,
|
|
|
|
"development".to_string(),
|
|
|
|
Some(experimental_metadata),
|
|
|
|
)),
|
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 10:05:39 +03:00
|
|
|
Box::new(PLUGIN_BYTES.clone()),
|
2022-09-18 12:54:06 +03:00
|
|
|
Some(json!({ "pluginConfig": "testValue" })),
|
2023-06-08 05:19:07 +03:00
|
|
|
None,
|
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 10:05:39 +03:00
|
|
|
);
|
2022-09-18 12:54:06 +03:00
|
|
|
|
|
|
|
serialized_program = plugin_transform_executor
|
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 10:05:39 +03:00
|
|
|
.transform(&serialized_program, Some(false))
|
2022-09-18 12:54:06 +03:00
|
|
|
.expect("Plugin should apply transform");
|
|
|
|
|
|
|
|
let program: Program = serialized_program
|
|
|
|
.deserialize()
|
2023-05-15 06:17:31 +03:00
|
|
|
.expect("Should able to deserialize")
|
|
|
|
.into_inner();
|
2022-09-18 12:54:06 +03:00
|
|
|
|
|
|
|
assert_eq!(parsed, program);
|
|
|
|
|
|
|
|
Ok(())
|
|
|
|
})
|
|
|
|
.expect("Should able to run multiple plugins transform");
|
|
|
|
|
|
|
|
Ok(())
|
|
|
|
}
|