refactor: use utility for cross-platform path regex construction

[james-elicx]

• Create a new utility for constructing regular expressions with cross-platform paths.
• Update usage to use the new utility.

[pkg-pr-new]

Open in Stackblitz

pnpm add https://pkg.pr.new/@opennextjs/aws@701

commit: 8d603ae

[changeset-bot]

🦋 Changeset detected

Latest commit: 8d603ae

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@opennextjs/aws	Patch
app-pages-router	Patch
app-router	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[conico974]

Why the escape options ? It's not used anywhere.
My take on this is that we should only escape path related stuff here (i.e. / the starting ./ and file extensions)

[vicb]

Why the escape options ?

That's something I asked James.

If you only want to escape a path then you would use the default value (true)

But sometimes (i.e. ESBuild filter), you might want to have more control on the pattern and do not escape special chars.

[vicb]

@james-elicx thanks for the change, LGTM.

Let's have more discussion with @conico974 about the exact behavior this should have

[vicb]

@conico974 replying here as the convo is resolved:

I understand your point but sounds like "only escape path related stuff here (i.e. / the starting ./ and file extensions)" is not without surprises either.

For now I feel like we have those solutions:

• only handle the separator
• handle the separator and escape the special chars (do not offer { escape: false } - I will come with a different function for my needs
• use the impl in this PR.

I need some think to think about it.

Notes:

• /(\/|\\)edgeFunctionHandler.js/g was wrongly escaped before this PR (only to say there is probably no ideal solution, as you mentioned we can get things wrong after this PR too)
• I think you replied before I updated my message

[conico974]

@vicb As you said there is probably no ideal solution for this ( unless with some typescript wizardry, but it's not worth the effort ).
Personally i would have just made it escape path related stuff, and if we need more complex stuff we just write our own regex.
But i'm fine with the current implementation as long as we provide enough explanation as to what needs to be done for these special cases.

[vicb]

Looks good to me, thanks for adding a clear doc and tests.

[conico974]

LGTM, Thanks