Please clarify documentation for edge functions excludedPath

Support Edge Functions
,
1

The documentation for edge functions says that “glob-style” expressions are supported, and links to the glob library on npm. Glob itself relies on minimatch (probably a better library to link to since it does all the string matching stuff).

I tried a excludedPath string like (reduced for brevity):

"/**/*.{js,json}"

Tested against minimatch, this string matches any JavaScript or JSON path (whether or not at the root). However, that is not the case, and this bit me. The excludedPath does not appear to understand the string properly, so I had to expand the path to:

["/*.js", "/**/*.js", "/*.json", "/**/*.json"]

Given how fiddly it can be to work with edge functions, some more detailed documentation around these paths would be welcome. Detailed examples would be especially appreciated.

2

Hi @qubyte, thanks for reaching out, and bringing this to our attention! We’re looking into it.

From my initial investigation, the difference in behaviour seems to come down to the globstar option. It seems like minimatch, like most modern glob matchers, by default has globstar matching enabled, while our implementation doesn’t (The link to minimatch is misleading, as we’re not using that as the implementation). We’re discussing this topic internally, and i’ll post an update once we have one.

3

Ah, thanks for the tip. That means my solution still isn’t quite right (I guess ** is getting treated as * or something). Another way out is for me to use a regular expression for excludedPattern… This might be as simple as "\\.(js|json)$" (it looks like this gets fed to something like the JavaScript RegExp constructor).

4

Not quite :sweat_smile:! That gives me an error:

FORMAT excluded_patterns must be an array of regex that starts with ^ and ends with $ (e.g. ^/blog/[d]{4}$)

Easily solved though: ^(.*)\\.(js|json)$

Probably also worth a mention in the docs. I don’t think the examples of patterns given there are valid given the above error message.

5

After an internal discussion on this yesterday, we’ll be rolling out a change that changes the matching implementation to use the browser-standard URLPattern. It’s fully compatible to the current matching, but it’s a browser standard and way more precise, so we hope there’s less surprise in that. I’ll update the docs on that once the rollout is complete. Thanks for poking us on this! :smiley:

I believe you should be able to put /*.{js,json} as your one excludedPath. This pattern should match all paths that end in .js or .json, which I believe is what you’re looking for.

Thanks for pointing this out! We’ll either update the docs or automatically add those ^...$ to regexes missing it - the current state definitely isn’t right :sweat_smile:

1 Like
6

After an internal discussion on this yesterday, we’ll be rolling out a change that changes the matching implementation to use the browser-standard URLPattern.

I flirted with suggesting this, but it seemed like a big ask. Amazing! Could you drop a note in this thread when that ships please?

I believe you should be able to put /*.{js,json}

I’ll give this a shot, thanks for the tip.

1 Like
8

We’ve shipped the URLPattern implementation over the past couple of days, and i’ve merged the docs update today. Thanks for raising this @qubyte, much welcome!

2 Likes
9

Amazing! Thank you and the team!

1 Like