feat: support regex for prerender.ignore

[thezzisu]

🔗 Linked issue

Resolves #308

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Enhance prerender.ignore with the ability to use RegExp.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[nuxt-studio]

✅ Live Preview ready!

Name	Edit	Preview	Latest Commit
nitro	Edit on Studio ↗︎	View Live Preview	91b4061

[thezzisu]

Notice: maybe conflict with #1032

[atinux]

Will first merge #1032 to rebase your branch

[atinux]

Fixed the conflicts and improve the docs at the same time.

[codecov]

Codecov Report

Merging #1033 (91b4061) into main (554b358) will decrease coverage by 0.05%.
The diff coverage is 16.66%.

@@            Coverage Diff             @@
##             main    #1033      +/-   ##
==========================================
- Coverage   67.59%   67.55%   -0.05%     
==========================================
  Files          62       62              
  Lines        6259     6263       +4     
  Branches      707      707              
==========================================
  Hits         4231     4231              
- Misses       2015     2019       +4     
  Partials       13       13              

Impacted Files	Coverage Δ
src/prerender.ts	88.13% <0.00%> (-1.22%)	⬇️
src/types/nitro.ts	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[atinux]

Wondering if we could add a test case for it as well.

[pi0]

I'm thinking we might be better first allow ** and * in ignore patterns to keep it consistent with route rules. We can also introduce a hook / function filter to allow ignoring routes on demand for more advanced cases.

[atinux]

Allowing the pattern ** and * will solve your usecase @thezzisu ?

[pi0]

I'm afraid not. According to linked issue, it requires custom logic which can be implemented by a custom hook / callback (internally can use also regex...)

[atinux]

So what are the next steps?

[thezzisu]

As @pi0 said, custom hooks/callbacks would be the most powerful solution; but, for most use cases, RegEx should be enough.

Allowing the pattern ** and * will solve your usecase @thezzisu ?

In fact, my use cases needs the power of "excluded ignore", which is not easily solvable with route rules matching. The underlying library, whose radix-tree-matching do not produce result with the same order as in the input.

[thezzisu]

Wondering if we could add a test case for it as well.

Should I implement more strict input checking? If the user uses TypeScript, the current solution will work fine.

[atinux]

I think it's fine for types using TS.

If I understand correctly, you don't want to support regex but the ability to give a function instead @pi0 ?

[pi0]

A hook would be nice for advanced usecases.

I prefer to keep ignore strict string pattern format as much as possible. This (same as route rules) is an advantage to be able static rules to provider rules which by introducing regexes to route defs we lose.

What do you think about introducing prerender.include as well:

prerender: {
  include: ['/static/**'],
  exclude: ['/**']
}

[thezzisu]

A hook would be nice for advanced usecases.

I prefer to keep ignore strict string pattern format as much as possible. This (same as route rules) is an advantage to be able static rules to provider rules which by introducing regexes to route defs we lose.

What do you think about introducing prerender.include as well:

prerender: {
  include: ['/static/**'],
  exclude: ['/**']
}

But how about the priority? Is the 'include' a 'negative exclude' like !blahblah syntax in .gitignore?

Since this option won't affect how route options work (in fact, it's a option for the crawler, not the server), I think RegExs should be fine.

[pi0]

But how about the priority?

The most precise rule takes into priority

Since this option won't affect how route options work

The point is route rule definition consistency and having most simple way to do things when possible.

[thezzisu]

But how about the priority?

The most precise rule takes into priority

Since this option won't affect how route options work

The point is route rule definition consistency and having most simple way to do things when possible.

OK. How about add a prerenderRules like routeRules that using the similar syntax Record<string, SomeOptions>?

[thezzisu]

But how about the priority?

The most precise rule takes into priority

Since this option won't affect how route options work

The point is route rule definition consistency and having most simple way to do things when possible.

OK. How about add a prerenderRules like routeRules that using the similar syntax Record<string, SomeOptions>?

The reason is that, routeRules is for server, but the prerender is a standalone thing though.

[pi0]

We do actually support prerender: true for routeRules (route rules are unified routing rules not limited to server).

We can indeed support prerender: false to allow overiridng for specific patterns 👍🏼

[thezzisu]

We do actually support prerender: true for routeRules (route rules are unified routing rules not limited to server).

We can indeed support prerender: false to allow overiridng for specific patterns 👍🏼

So the problem is I want to make / not prerendered (SSR) when using the server built by nuxt build, but to be prerendered when using nuxt generate.

[pi0]

Yes that would be possible! (SSR renderer won't be affected by prerender rule only nitro prerender/nuxt generate uses this specific rule).

[thezzisu]

Sorry for the delay. Now the problems becomes that the https://github.com/unjs/radix3#route-matcher is not matching the most specific rule! Let's see a example below:

Simple swapping the rules will affect the output.

[atinux]

Nice catch @thezzisu

It seems we need a way to prioritize the routes for best matching strategy, similar to what vue-router 4 is doing 🤔

[thezzisu]

I think this would be a better solution than supporting regex. I'll close this pull request, and open a issue on unjs/radix3 instead.

[pi0]

Radix 3 basically does that :) but we don't use it internally in nitro prerender inference...

[atinux]

So open back an issue in Nitro pre-render to support this I guess 😅

[pi0]

~> #1078