chore(plugin): expose optional features for wasm plugin test

[aircloud]

Description:

At present, the default features of wasmer are not exposed by default, so if third-party plugin developers want to use the swc to write some test code, it will be difficult.

For example, if there is no default feature of wasmer, developers using related capabilities will report errors like the following:

error: At least the `host-fs` or the `mem-fs` feature must be enabled. Please, pick one.
 --> /Users/xxx/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd/wasmer-vfs-2.2.1/src/lib.rs:9:1
  |
9 | compile_error!("At least the `host-fs` or the `mem-fs` feature must be enabled. Please, pick one.");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Moreover, I haven't found a way to directly specify the dependency's dependency features in rust, so I think adding some optional features to swc may be a solution. This will not affect normal use.

Of course, if there are other ways to accomplish this ability, it is also OK

Here's an my test code example based on other developers' versions in the community(
The test now fails to compile): https://github.com/aircloud/swc-plugin-console-prefix/blob/feat/swc_2022_04/src/lib.rs

BREAKING CHANGE:

None

Related issue (if exists):

None

[kdy1]

I'm against this change.
This will make CI much slower.
Users can depend on wasmer by themselves

[aircloud]

Users can depend on wasmer by themselves won't solve the problem well.

But I agree with the latter point of view. I can turn off this PR first and wait for your solution~

[kwonoj]

Mainly, I'm a bit hesitant to expose explicitly wasmer_* as features to the downstream who want to use. Runtime we use should be implementation detail we can change anytime.

[kdy1]

@kwonoj I think you are right. So we should expose a feature, right?
Otherwise user have to depend on wasmer

[kwonoj]

yes, I think it makes sense swc* exposes a feature to let user controls. But name should not include anything 'wasmer'.

[aircloud]

So I am waiting for you to add this feature, should this PR be closed?

[kwonoj]

I think you can update PR to rename features, also to not to try to include some features by default.

[aircloud]

I think you can update PR to rename features, also to not to try to include some features by default.

I'll think about it and update it later

[aircloud]

I thought again about the related issue

I found that in addition to the problem I reported above, after enabling the plugin feature, there is a simple problem that will cause the simplest import to fail to compile.

// in Cargo.toml:
[dependencies]
swc = { version = "0.161.1",  features = ["plugin"] } 

// in main.rs:
use swc;

// error:
error: At least the `host-fs` or the `mem-fs` feature must be enabled. Please, pick one.
 --> /Users/aircloud/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd/wasmer-vfs-2.2.1/src/lib.rs:9:1
  |
9 | compile_error!("At least the `host-fs` or the `mem-fs` feature must be enabled. Please, pick one.");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Compiling region v3.0.0

Combined with the problems here, I think it is necessary to expose an additional feature to use swc with plugin function for rust developers.

So I re-integrated and called this feature plugin-dev temporarily.

For rust developers, just use plugin-dev.

Other names are OK, but there should be such a feature right?

how about this? @kwonoj

[kdy1]

Plugin authors are not supposed to depend on swc

[aircloud]

Plugin authors are not supposed to depend on swc

emm, Is this sample code(just for test) not recommended? @kdy1

https://github.com/aircloud/swc-plugin-console-prefix/blob/feat/swc_2022_04/examples/usage.rs

[kdy1]

Yes, it's not recommended

[kwonoj]

As already explained, it is discouraged to have swc, or anything else as a dependency to the plugin. The only deps plugin may rely on is swc_plugin. (There are some exceptions like swc_ecma_quote due to proc_macro.)

[aircloud]

As already explained, it is discouraged to have swc, or anything else as a dependency to the plugin. The only deps plugin may rely on is swc_plugin. (There are some exceptions like swc_ecma_quote due to proc_macro.)

I know this

But I do sometimes want to write a little rust test in the plugin repository, so I hope to introduce swc in [dev-dependencies]

[dependencies]
swc_plugin = "0.47.0"

[dev-dependencies]
swc = { version="xx", features = ["plugin", "plugin-dev"] }
swc_common = {  version="xx",, features = ["tty-emitter"] }

But you don't seem to recommend this approach, I'm very confused now.

So how to write rust test code for the plugin (Mock a real calling environment instead of simple unit tests)? @kwonoj

[kwonoj]

Most of cases test would be performed with swc_ecma_transforms_testing. Yes, it is a unit test.

It is not impossible to run whole via swc, but we do not recommend it as standard practice, and you may try it on your own.

[aircloud]

Thank you, I understand what you mean

I don't seem to have any more ideas for this PR (although If no feature is to be added, It is hard to use swc to test the whole case in rust, like i said before. Maybe I just have to give up using it like this)