ref(nextjs): Use virtual rather than temporary file for proxy module

[lobsterkatie]

In the proxy loader used by the nextjs SDK to autowrap user code, we currently write a temporary file to disk for each proxy module we create, because by default Rollup's API expects a path to a file, not the file's contents. It's a little bit of an ugly hack, though, and can cause problems because it writes to the user's source directory rather than to their build directory.

This switches to the use of virtual files, using the @rollup/virtual-plugin plugin. For unclear reasons, this seems to change (and not in a good way) the base of the relative paths calculated by Rollup when transforming the proxy templates' import * as wrappedFile from <wrapped file> and export * from <wrapped file> statements. We already have to manually fix those statements, to undo the fact that Rollup substitutes underscores for any square brackets which appear in the paths, but that fix is straightforward because it's very easy to predict what the wrong version will look like, so finding it and overwriting it with the right version is easy.

With the relative path base change introduced by the virtual plugin it's not as simple, though, because there's not an easily-discernible pattern to what new base gets picked. (Sometimes it's pages/, sometimes it's pages/api, sometimes the path uses ./xxx, sometimes the path uses ../xxx...) Therefore, rather than trying to nail down and then handle each case of that logic in order to predict what the incorrect path will be, this looks for the transformed version of the whole import * as wrappedFile from <wrapped file> statement and reads the incorrect path from there using a regex.

Note: This is a second attempt at #5960, which was reverted. H/t to the author of that PR, @lforst, for rubber-ducking this new solution.

Fixes #5944.

[lforst]

l: Is there a way we could replace using a capture group?

Or do something like

code.replace(/import \* as wrapee from '(.*)';/g, `./${path.basename(userModulePath)}`)

non-null assertion is a bit scary.

[lobsterkatie]

It is using a capture group (that's what the [1] is), it's just doing it in two steps rather than one, both because it makes it more readable and because we actually need the error which will get thrown if the regex doesn't match, in order to trigger the proxy loader to warn the user and return the original code untouched. If we do it in one step as you have above, and the regex doesn't match, the replacement will fail silently, and the code will be returned with the broken path. (That said, we are in total control of the value of code, because it comes from our code processing our template, and so we can guarantee that the first line will indeed match that regex.)

I can add a comment explaining this.