feat(swc/plugin): support context for the plugin transform

[kwonoj]

Description:

From discussion #3540 (comment).

Plugin may need additional data other than config to plugin itself, mostly state around swc/core. Some examples like

• specific file name for current transform
• maybe whole swcrc config, not only for the plugin itself

or possibly more. This PR attempts to resolve those by forwarding new param named context.

There are few possible approaches to enable this.

1. expand plugin interface param signature

#[plugin_transform]
fn process(program: Program, plugin_config: String, filename: String, swcrc: String...);

Obviously, this is not preferrable as we'll continously expand signatures and each time we add new param it'll cause breaking changes.

2. Typed struct param

struct PluginContext {
 filename: String,
 other: ...
}

#[plugin_transform]
fn process(program: Program, plugin_config: String, context: PluginContext);

This is most clear interface signature. However, have same pitfall as first. Each time we add new properties into struct, it'll be a breaking change since our serialization does not support add-only / versioned

3. Context as JSON-string

Current approach. Safe to add new properties since it's string, plugin can try to pick up necessary properties for their use.

Though I picked 3rd, I'm currently bit debating 2 also - if we can add enough context properties in experimental phase, we can stabilize those to avoid frequent breaking changes. The part I'm not sure is how frequent we'll need to change this context information. Would like to hear thoughts, and update PR into second if needed.

BREAKING CHANGE:
Plugin will need to accept 3rd param in any case, it could be a string or a typed struct.

Related issue (if exists):

#3540 (comment).

[kwonoj]

Actually I'm slightly leaning toward to 2 at this moment. We'll need to figure out what properties we'll expose in that case.

[kdy1]

Thanks!
Can you rebase it?

[kwonoj]

Yup, was doing it already. 🚢

[kdy1]

I think we should rename variables.

[kdy1]

This should use base instead.

[kdy1]

source_file_name is used to control sourcemap, and base is the filename.
It's named base because the parameter is introduced because of paths support, but I think it's a bad name.

[kwonoj]

yes, I was confused by name actually.

[kdy1]

LGTM.