Open zhangtao25 opened 1 month ago
cc @kwonoj Any opinion about this?
Currently, with TransformPluginMetadataContextKind, I can only retrieve the NODE_ENV from Node.js.
We should allow env::var
I guess, but I want to hear opinions of the core team about this. @swc-project/core-es
I know that the current WASM version of SWC doesn't support plugins. However, if this feature is added, would it complicate the implementation of WASM SWC with plugins?
I think it's only about allowing env::var
from Wasm plugins, with wasm32-wasi
runtime target.
I recall whole env varables for the process could be quite verbose and passing it all would cause some overload.
If we have to pass something, I'd consider to have sort of allowlist can be configured and pass it through metadatacontext.
We don’t need to explicitly pass them I think, I think we can support env::var for Wasi
Isn't env::var eventually need to be serialized / deserialized its values into wasm's memory space? that's the one I'm worrying about. It is easily possible to see some proc have more than 20-30 vars or even ~100 depends on the usecase.
Oops. I expected wasi
to have a feature for it, but well... https://docs.rs/wasmer-wasix/latest/wasmer_wasix/capabilities/struct.Capabilities.html
There's no capability to allow fetching the environment variables from os
There should be @kdy1 , I believe we support this on the wasmer-cli
via --forward-host-env
, so it should be doable to have it on the WASIX api. If you want, feel free to open an issue in the Wasmer repo and we can follow-up there
Describe the feature
We have developed a swc plugin that expects to detect the environment variables of the current ci environment when the plugin is running, but the swc plugin as of now only accepts explicitly passed parameters from outside, and we want to implement this directly inside the plugin.
Babel plugin or link to the feature description
https://github.com/canyon-project/canyon/blob/main/plugins/babel-plugin-canyon/src/index.js#L24
Additional context
No response