[Feature Request]: Using RegExp for resolvedPaths

[akku1139]

What problem does this feature solve?

Currently string[] is allowed in the JS plugin load.filters.resolvedPaths , transform.filters.resolvedPaths .
https://github.com/farm-fe/farm/blob/main/packages/core/src/plugin/type.ts#L179
Since regular expressions are set here,
I think it would be more convenient to be able to specify JavaScript native RegExp .
Plugin writer can also use \ instead of \\ for escapes by backslashes.

What does the proposed API look like?

  load: {
    filters: { resolvedPaths: [/\.md$/] },

[fu050409]

Using regular expressions with js native does sound great, but farm is napi based and the core code is all Rust. Complex object passing across programming languages can have unimaginable overhead (in fact, farm's benchmarks show that in small front-end projects, the overhead of such data transfer is huge, and is even the main time-consuming part of the compilation process), so I guess it's better that we use strings instead of js native strings.

[akku1139]

How about RegExp.prototype.toString() ?
This allows Farm to pass RegExp as a string to the Rust backend in the same way.
However, some regular expressions are not compatible with ECMA Script and regex crate.
This may be a bad way.

[wre232114]

We will discuss about it, it may be opitimized in v2

[fu050409]

How about RegExp.prototype.toString() ? This allows Farm to pass RegExp as a string to the Rust backend in the same way. However, some regular expressions are not compatible with ECMA Script and regex crate. This may be a bad way.

I think the compatibility between js regex and regex crate is not the most critical, since regex crate allows all most common usage the regular expressions. However, it seems meaningless to covert all js RegExp to string? We can't provide too many efficiency but more overheads..?

Whatever, I will try to make benchmarks and maybe also a survey. If the overheads are acceptable, we may consider change the api