2022-09-10 06:50:54 +03:00
|
|
|
#![cfg_attr(not(feature = "__rkyv"), allow(warnings))]
|
|
|
|
|
2021-11-28 11:02:14 +03:00
|
|
|
use std::{
|
|
|
|
env, fs,
|
|
|
|
path::{Path, PathBuf},
|
|
|
|
process::{Command, Stdio},
|
2022-07-27 07:16:44 +03:00
|
|
|
sync::Arc,
|
2021-11-28 11:02:14 +03:00
|
|
|
};
|
2022-02-09 09:33:32 +03:00
|
|
|
|
|
|
|
use anyhow::{anyhow, Error};
|
2022-07-27 07:16:44 +03:00
|
|
|
use serde_json::json;
|
2022-09-09 11:05:51 +03:00
|
|
|
#[cfg(feature = "__rkyv")]
|
|
|
|
use swc_common::plugin::serialized::PluginSerializedBytes;
|
2022-07-07 10:46:49 +03:00
|
|
|
use swc_common::{
|
2022-09-09 11:05:51 +03:00
|
|
|
collections::AHashMap, errors::HANDLER, plugin::metadata::TransformPluginMetadataContext,
|
|
|
|
sync::Lazy, FileName, Mark,
|
2022-07-07 10:46:49 +03:00
|
|
|
};
|
2022-01-11 13:11:04 +03:00
|
|
|
use swc_ecma_ast::{CallExpr, Callee, EsVersion, Expr, Lit, MemberExpr, Program, Str};
|
2023-03-30 11:06:02 +03:00
|
|
|
use swc_ecma_parser::{parse_file_as_program, Syntax};
|
2022-01-10 15:34:16 +03:00
|
|
|
use swc_ecma_visit::{Visit, VisitWith};
|
2021-11-28 11:02:14 +03:00
|
|
|
|
2023-06-19 08:49:45 +03:00
|
|
|
static TARGET_DIR: Lazy<PathBuf> = Lazy::new(|| {
|
|
|
|
cargo_metadata::MetadataCommand::new()
|
|
|
|
.no_deps()
|
|
|
|
.exec()
|
|
|
|
.unwrap()
|
|
|
|
.target_directory
|
|
|
|
.into()
|
|
|
|
});
|
|
|
|
|
2021-11-28 11:02:14 +03:00
|
|
|
/// Returns the path to the built plugin
|
|
|
|
fn build_plugin(dir: &Path) -> Result<PathBuf, Error> {
|
|
|
|
{
|
2022-01-24 09:13:30 +03:00
|
|
|
let mut cmd = Command::new("cargo");
|
2023-06-19 08:49:45 +03:00
|
|
|
cmd.env("CARGO_TARGET_DIR", &*TARGET_DIR);
|
2021-11-28 11:02:14 +03:00
|
|
|
cmd.current_dir(dir);
|
2022-01-24 09:13:30 +03:00
|
|
|
cmd.args(["build", "--target=wasm32-wasi"])
|
|
|
|
.stderr(Stdio::inherit());
|
|
|
|
cmd.output()?;
|
2022-07-11 04:44:00 +03:00
|
|
|
|
|
|
|
if !cmd
|
|
|
|
.status()
|
|
|
|
.expect("Exit code should be available")
|
|
|
|
.success()
|
|
|
|
{
|
|
|
|
return Err(anyhow!("Failed to build plugin"));
|
|
|
|
}
|
2021-11-28 11:02:14 +03:00
|
|
|
}
|
|
|
|
|
2023-06-19 08:49:45 +03:00
|
|
|
for entry in fs::read_dir(&TARGET_DIR.join("wasm32-wasi").join("debug"))? {
|
2021-11-28 11:02:14 +03:00
|
|
|
let entry = entry?;
|
|
|
|
|
|
|
|
let s = entry.file_name().to_string_lossy().into_owned();
|
2022-01-07 09:13:46 +03:00
|
|
|
if s.eq_ignore_ascii_case("swc_internal_plugin.wasm") {
|
2021-11-28 11:02:14 +03:00
|
|
|
return Ok(entry.path());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Err(anyhow!("Could not find built plugin"))
|
|
|
|
}
|
|
|
|
|
2022-01-10 15:34:16 +03:00
|
|
|
struct TestVisitor {
|
|
|
|
pub plugin_transform_found: bool,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Visit for TestVisitor {
|
|
|
|
fn visit_call_expr(&mut self, call: &CallExpr) {
|
2022-01-10 16:54:42 +03:00
|
|
|
if let Callee::Expr(expr) = &call.callee {
|
2022-01-10 15:34:16 +03:00
|
|
|
if let Expr::Member(MemberExpr { obj, .. }) = &**expr {
|
2022-01-10 16:54:42 +03:00
|
|
|
if let Expr::Ident(ident) = &**obj {
|
|
|
|
if ident.sym == *"console" {
|
|
|
|
let args = &*(call.args[0].expr);
|
|
|
|
if let Expr::Lit(Lit::Str(Str { value, .. })) = args {
|
|
|
|
self.plugin_transform_found = value == "changed_via_plugin";
|
2022-01-10 15:34:16 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
#[cfg(feature = "__rkyv")]
|
|
|
|
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_internal_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-09 11:05:51 +03:00
|
|
|
#[cfg(feature = "__rkyv")]
|
2021-11-28 11:02:14 +03:00
|
|
|
#[test]
|
|
|
|
fn internal() -> Result<(), Error> {
|
2023-05-15 06:17:31 +03:00
|
|
|
use swc_common::plugin::serialized::VersionedSerializable;
|
|
|
|
|
2022-01-11 13:11:04 +03:00
|
|
|
// run single plugin
|
2021-11-28 11:02:14 +03:00
|
|
|
testing::run_test(false, |cm, _handler| {
|
|
|
|
let fm = cm.new_source_file(FileName::Anon, "console.log(foo)".into());
|
|
|
|
|
2022-02-26 09:41:14 +03:00
|
|
|
let program = parse_file_as_program(
|
|
|
|
&fm,
|
2023-03-30 11:06:02 +03:00
|
|
|
Syntax::Es(Default::default()),
|
2021-11-28 11:02:14 +03:00
|
|
|
EsVersion::latest(),
|
|
|
|
None,
|
2022-02-26 09:41:14 +03:00
|
|
|
&mut vec![],
|
|
|
|
)
|
|
|
|
.unwrap();
|
2021-11-28 11:02:14 +03:00
|
|
|
|
2023-05-15 06:17:31 +03:00
|
|
|
let program = PluginSerializedBytes::try_serialize(&VersionedSerializable::new(program))
|
|
|
|
.expect("Should serializable");
|
2022-07-27 07:16:44 +03:00
|
|
|
let experimental_metadata: AHashMap<String, String> = [
|
|
|
|
(
|
|
|
|
"TestExperimental".to_string(),
|
|
|
|
"ExperimentalValue".to_string(),
|
|
|
|
),
|
|
|
|
("OtherTest".to_string(), "OtherVal".to_string()),
|
|
|
|
]
|
|
|
|
.into_iter()
|
|
|
|
.collect();
|
2022-01-11 13:11:04 +03:00
|
|
|
|
2022-07-27 07:16:44 +03:00
|
|
|
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-07-27 07:16:44 +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-07-27 07:16:44 +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-02-18 08:50:51 +03:00
|
|
|
|
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
|
|
|
/* [TODO]: reenable this later
|
2022-08-25 19:10:47 +03:00
|
|
|
assert!(!plugin_transform_executor
|
|
|
|
.plugin_core_diag
|
|
|
|
.pkg_version
|
|
|
|
.is_empty());
|
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-08-23 02:48:50 +03:00
|
|
|
|
2022-07-08 09:02:42 +03:00
|
|
|
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-07-08 09:02:42 +03:00
|
|
|
.expect("Plugin should apply transform");
|
2022-01-10 15:34:16 +03:00
|
|
|
|
2022-07-06 07:42:00 +03:00
|
|
|
let program: Program = program_bytes
|
|
|
|
.deserialize()
|
2023-05-15 06:17:31 +03:00
|
|
|
.expect("Should able to deserialize")
|
|
|
|
.into_inner();
|
2022-01-11 13:11:04 +03:00
|
|
|
let mut visitor = TestVisitor {
|
|
|
|
plugin_transform_found: false,
|
|
|
|
};
|
|
|
|
program.visit_with(&mut visitor);
|
|
|
|
|
|
|
|
visitor
|
|
|
|
.plugin_transform_found
|
|
|
|
.then(|| visitor.plugin_transform_found)
|
|
|
|
.ok_or(())
|
|
|
|
})
|
|
|
|
.expect("Should able to run single plugin transform");
|
|
|
|
|
2022-01-25 11:13:39 +03:00
|
|
|
// run single plugin with handler
|
|
|
|
testing::run_test2(false, |cm, handler| {
|
|
|
|
let fm = cm.new_source_file(FileName::Anon, "console.log(foo)".into());
|
|
|
|
|
2022-02-26 09:41:14 +03:00
|
|
|
let program = parse_file_as_program(
|
|
|
|
&fm,
|
2023-03-30 11:06:02 +03:00
|
|
|
Syntax::Es(Default::default()),
|
2022-01-25 11:13:39 +03:00
|
|
|
EsVersion::latest(),
|
|
|
|
None,
|
2022-02-26 09:41:14 +03:00
|
|
|
&mut vec![],
|
|
|
|
)
|
|
|
|
.unwrap();
|
2022-01-25 11:13:39 +03:00
|
|
|
|
2023-05-15 06:17:31 +03:00
|
|
|
let program = PluginSerializedBytes::try_serialize(&VersionedSerializable::new(program))
|
|
|
|
.expect("Should serializable");
|
2022-07-27 07:16:44 +03:00
|
|
|
let experimental_metadata: AHashMap<String, String> = [
|
|
|
|
(
|
|
|
|
"TestExperimental".to_string(),
|
|
|
|
"ExperimentalValue".to_string(),
|
|
|
|
),
|
|
|
|
("OtherTest".to_string(), "OtherVal".to_string()),
|
|
|
|
]
|
|
|
|
.into_iter()
|
|
|
|
.collect();
|
2022-01-25 11:13:39 +03:00
|
|
|
|
|
|
|
let _res = HANDLER.set(&handler, || {
|
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
|
|
|
let mut plugin_transform_executor = swc_plugin_runner::create_plugin_transform_executor(
|
|
|
|
&cm,
|
|
|
|
&Mark::new(),
|
|
|
|
&Arc::new(TransformPluginMetadataContext::new(
|
|
|
|
None,
|
|
|
|
"development".to_string(),
|
|
|
|
Some(experimental_metadata),
|
|
|
|
)),
|
|
|
|
Box::new(PLUGIN_BYTES.clone()),
|
|
|
|
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-07-08 09:02:42 +03:00
|
|
|
|
|
|
|
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-07-08 09:02:42 +03:00
|
|
|
.expect("Plugin should apply transform")
|
2022-01-25 11:13:39 +03:00
|
|
|
});
|
|
|
|
|
|
|
|
Ok(())
|
|
|
|
})
|
|
|
|
.expect("Should able to run single plugin transform with handler");
|
|
|
|
|
2022-01-11 13:11:04 +03:00
|
|
|
// Run multiple plugins.
|
|
|
|
testing::run_test(false, |cm, _handler| {
|
|
|
|
let fm = cm.new_source_file(FileName::Anon, "console.log(foo)".into());
|
|
|
|
|
2022-02-26 09:41:14 +03:00
|
|
|
let program = parse_file_as_program(
|
|
|
|
&fm,
|
2023-03-30 11:06:02 +03:00
|
|
|
Syntax::Es(Default::default()),
|
2022-01-11 13:11:04 +03:00
|
|
|
EsVersion::latest(),
|
|
|
|
None,
|
2022-02-26 09:41:14 +03:00
|
|
|
&mut vec![],
|
|
|
|
)
|
|
|
|
.unwrap();
|
2022-01-11 13:11:04 +03:00
|
|
|
|
2022-07-06 07:42:00 +03:00
|
|
|
let mut serialized_program =
|
2023-05-15 06:17:31 +03:00
|
|
|
PluginSerializedBytes::try_serialize(&VersionedSerializable::new(program))
|
|
|
|
.expect("Should serializable");
|
2022-01-11 13:11:04 +03:00
|
|
|
|
2022-07-27 07:16:44 +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-07-27 07:16:44 +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-07-27 07:16:44 +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-07-21 08:34:48 +03:00
|
|
|
|
2022-07-08 09:02:42 +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-07-08 09:02:42 +03:00
|
|
|
.expect("Plugin should apply transform");
|
2022-01-11 13:11:04 +03:00
|
|
|
|
|
|
|
// TODO: we'll need to apply 2 different plugins
|
2022-07-27 07:16:44 +03:00
|
|
|
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-07-27 07:16:44 +03:00
|
|
|
&Arc::new(TransformPluginMetadataContext::new(
|
|
|
|
None,
|
|
|
|
"development".to_string(),
|
2022-08-25 19:10:47 +03:00
|
|
|
Some(experimental_metadata),
|
2022-07-27 07:16:44 +03:00
|
|
|
)),
|
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-07-27 07:16:44 +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-07-08 09:02:42 +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-07-08 09:02:42 +03:00
|
|
|
.expect("Plugin should apply transform");
|
2022-01-11 13:11:04 +03:00
|
|
|
|
2022-07-06 07:42:00 +03:00
|
|
|
let program: Program = serialized_program
|
|
|
|
.deserialize()
|
2023-05-15 06:17:31 +03:00
|
|
|
.expect("Should able to deserialize")
|
|
|
|
.into_inner();
|
2022-01-10 15:34:16 +03:00
|
|
|
let mut visitor = TestVisitor {
|
|
|
|
plugin_transform_found: false,
|
|
|
|
};
|
|
|
|
program.visit_with(&mut visitor);
|
2021-11-28 11:02:14 +03:00
|
|
|
|
2022-01-10 15:34:16 +03:00
|
|
|
visitor
|
|
|
|
.plugin_transform_found
|
|
|
|
.then(|| visitor.plugin_transform_found)
|
|
|
|
.ok_or(())
|
2021-11-28 11:02:14 +03:00
|
|
|
})
|
2022-01-11 13:11:04 +03:00
|
|
|
.expect("Should able to run multiple plugins transform");
|
2021-11-28 11:02:14 +03:00
|
|
|
|
|
|
|
Ok(())
|
|
|
|
}
|