**Description:**
Previously it was impossible to minify non-strict code (e.g. `delete identifier;`) because `minify()` unconditionally parsed the input as a module regardless of the `module` setting.
**BREAKING CHANGE:**
`minify()` now respects the `module` parameter instead of ignoring it, so users who had been processing modules with `minify()` without passing `{ module: true }` will now need to pass it.
**Related issue**
- Closes#6130.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
**Description:**
- `jsc.experimental.keepImportAssertions` is renamed to `jsc.experimental.keepImportAttributes`.
- `jsc.experimental.emitAssertForImportAttributes` is added.
**Related issue:**
- Closes#7908
**Description:**
This adds the ability to not include `ahash` with swc_common, which
caused some issues for me compiling dprint-plugin-typescript to Wasm
because of:
```
Compiling ahash v0.8.3
Compiling getrandom v0.2.10
error: the wasm*-unknown-unknown targets are not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
--> C:\Users\david\.cargo\registry\src\index.crates.io-6f17d22bba15001f\getrandom-0.2.10\src\lib.rs:285:9
|
285 | / compile_error!("the wasm*-unknown-unknown targets are not supported by \
286 | | default, you may need to enable the \"js\" feature. \
287 | | For more information see: \
288 | | https://docs.rs/getrandom/#webassembly-support");
| |________________________________________________________________________^
```
(I can't enable the JS feature because it's running the wasm file in
Wasmer and also I don't support Wasi in dprint plugins)
**BREAKING CHANGE:**
This removes swc_common's "perf" feature and makes it the default, then
adds an `ahash` feature instead. An alternative would be to make the
`ahash` dep optional and part of the default features, then do
`default-features = false` in the downstream crates (I think, but I'm
not sure), but I figure most people will be using the perf default
anyway? I'm not sure what's preferable.
**Related issue:**
- Closes#7729.
**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.
