When generating a joinPoint proxy module in the webpack plugin, a webpackContext is generated, relative to the directory of the base module. As per the documentation for require.context (which import.meta.webpackContext is an alias of) this is designed for searching beneath a directory, potentially recursively, for matching files.

This lends itself nicely to variations that sit underneath the base module in the filesystem hierarchy. But where variations may be siblings, perhaps in a parallel hierarchy to the main filesystem, the regular expression generated will inevitably start with \.\.\/ (to look above the join point folder) which webpackContext does not appear to support.

To remove this restriction, the work of the context module can be re-created manually, since it ultimately ends up with a simple data structure mapping keys to statically-imported modules. This can also use standard javascript, rather than Webpack-specific extensions, which may be advantageous for future portability. Similarly, rather than the bespoke require.context data structure, moving to a conventional Map would be advantageous in consumers, too, and open the possibility of sharing these with a non-webpack plugin (see #7)