2023-01-26 05:09:36 +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;
|
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
|
|
|
use swc_common::{collections::AHashMap, plugin::metadata::TransformPluginMetadataContext, Mark};
|
2023-01-26 05:09:36 +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};
|
2023-01-26 05:09:36 +03:00
|
|
|
use swc_ecma_visit::Visit;
|
2023-06-21 06:16:33 +03:00
|
|
|
use testing::CARGO_TARGET_DIR;
|
2023-06-19 08:49:45 +03:00
|
|
|
|
2023-01-26 05:09:36 +03:00
|
|
|
/// Returns the path to the built plugin
|
|
|
|
fn build_plugin(dir: &Path, crate_name: &str) -> 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);
|
2023-01-26 05:09:36 +03:00
|
|
|
cmd.current_dir(dir);
|
|
|
|
cmd.args(["build", "--release", "--target=wasm32-wasi"])
|
|
|
|
.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"))? {
|
2023-01-26 05:09:36 +03:00
|
|
|
let entry = entry?;
|
|
|
|
|
|
|
|
let s = entry.file_name().to_string_lossy().into_owned();
|
|
|
|
if s.eq_ignore_ascii_case(&format!("{}.wasm", crate_name)) {
|
|
|
|
return Ok(entry.path());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Err(anyhow!("Could not find built plugin"))
|
|
|
|
}
|
|
|
|
|
|
|
|
struct TestVisitor {
|
|
|
|
pub plugin_transform_found: bool,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Visit for TestVisitor {
|
|
|
|
fn visit_call_expr(&mut self, call: &CallExpr) {
|
|
|
|
if let Callee::Expr(expr) = &call.callee {
|
|
|
|
if let Expr::Member(MemberExpr { obj, .. }) = &**expr {
|
|
|
|
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";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(feature = "__rkyv")]
|
|
|
|
#[test]
|
|
|
|
fn issue_6404() -> Result<(), Error> {
|
2023-05-15 06:17:31 +03:00
|
|
|
use swc_common::plugin::serialized::VersionedSerializable;
|
|
|
|
|
2023-01-26 05:09:36 +03:00
|
|
|
let plugin_path = build_plugin(
|
|
|
|
&PathBuf::from(env::var("CARGO_MANIFEST_DIR")?)
|
|
|
|
.join("tests")
|
|
|
|
.join("fixture")
|
|
|
|
.join("issue_6404"),
|
|
|
|
"swc_issue_6404",
|
|
|
|
)?;
|
|
|
|
|
|
|
|
dbg!("Built!");
|
|
|
|
|
|
|
|
// run single plugin
|
|
|
|
testing::run_test(false, |cm, _handler| {
|
|
|
|
let fm = cm
|
|
|
|
.load_file("../swc_ecma_minifier/benches/full/typescript.js".as_ref())
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
let program = parse_file_as_program(
|
|
|
|
&fm,
|
2023-03-30 11:06:02 +03:00
|
|
|
Syntax::Es(Default::default()),
|
2023-01-26 05:09:36 +03:00
|
|
|
EsVersion::latest(),
|
|
|
|
None,
|
|
|
|
&mut vec![],
|
|
|
|
)
|
|
|
|
.unwrap();
|
|
|
|
|
2023-05-15 06:17:31 +03:00
|
|
|
let program = PluginSerializedBytes::try_serialize(&VersionedSerializable::new(program))
|
|
|
|
.expect("Should serializable");
|
2023-01-26 05:09:36 +03:00
|
|
|
let experimental_metadata: AHashMap<String, String> = [
|
|
|
|
(
|
|
|
|
"TestExperimental".to_string(),
|
|
|
|
"ExperimentalValue".to_string(),
|
|
|
|
),
|
|
|
|
("OtherTest".to_string(), "OtherVal".to_string()),
|
|
|
|
]
|
|
|
|
.into_iter()
|
|
|
|
.collect();
|
|
|
|
|
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 raw_module_bytes =
|
|
|
|
std::fs::read(&plugin_path).expect("Should able to read plugin bytes");
|
|
|
|
let store = wasmer::Store::default();
|
|
|
|
let module = wasmer::Module::new(&store, raw_module_bytes).unwrap();
|
|
|
|
|
|
|
|
let plugin_module = swc_plugin_runner::plugin_module_bytes::CompiledPluginModuleBytes::new(
|
|
|
|
plugin_path
|
|
|
|
.as_os_str()
|
|
|
|
.to_str()
|
|
|
|
.expect("Should able to get path")
|
|
|
|
.to_string(),
|
|
|
|
module,
|
|
|
|
store,
|
|
|
|
);
|
|
|
|
|
2023-01-26 05:09:36 +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(),
|
2023-01-26 05:09:36 +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_module),
|
2023-01-26 05:09:36 +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
|
|
|
);
|
2023-01-26 05:09:36 +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 test
|
2023-01-26 05:09:36 +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
|
|
|
*/
|
2023-01-26 05:09:36 +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))
|
2023-01-26 05:09:36 +03:00
|
|
|
.expect("Plugin should apply transform");
|
|
|
|
|
|
|
|
let _: Program = program_bytes
|
|
|
|
.deserialize()
|
2023-05-15 06:17:31 +03:00
|
|
|
.expect("Should able to deserialize")
|
|
|
|
.into_inner();
|
2023-01-26 05:09:36 +03:00
|
|
|
|
|
|
|
Ok(())
|
|
|
|
})
|
|
|
|
.expect("Should able to run single plugin transform");
|
|
|
|
|
|
|
|
Ok(())
|
|
|
|
}
|