3.0.2
https://codesandbox.io/s/lykxn57kr7
Prefix routes are fine when they don't have a prefix but with a /sth/ it becomes problematic.
This causes problems especially for nuxt-i18n together with a catch-all-route (as it uses lang prefixes)
Info: This did not happen in 3.0.1
Related: #2496, #2503
No warning
Warning
Update: @clarkdo fixed that in Nuxt via https://github.com/nuxt/nuxt.js/pull/4394/files#diff-90f8231837497e514ba4e8e477131204R437
Maybe we could apply the same fix (as the original part is still in the code as is https://github.com/nuxt/nuxt.js/pull/4394/files) or revert the change? 鈽猴笍
I think it's better to modify the check done to display the warning 馃槅
@posva Well, https://github.com/vuejs/vue-router/blob/cf9dc11d92f5f3e55baa78d4d443fa41bf613d73/dist/vue-router.js#L828 is part of the pathToRegexp package.
Related src file:
https://github.com/vuejs/vue-router/blob/deba65a3235d399b245c963a9c626a341cbd67cc/src/util/params.js#L1-L27
I mean we should be able to do it in the warning check. I haven't checked it at runtime, but I'm talking about util/params.js
This bug triggers when calling router.resolve() with params: {pathMatch: 'foo'} when matching against existing routes that have * wildcard. That makes me wonder what will happen if we are trying to resolve with params: {pathMatch: 'foo'} and there is actual route that defines param called pathMatch. It would then match, which would likely be incorrect. It might be a bit of a stretch but...
I wonder if the special case of 'unnamed' param might need a more tailored approach here.
(BTW. This bug is a recent regression related to pathMatch stuff so I would consider it more than just an 'improvement'. It means that with perfectly valid setup, one can now get warnings when matching routes.)
Most helpful comment
(BTW. This bug is a recent regression related to
pathMatchstuff so I would consider it more than just an 'improvement'. It means that with perfectly valid setup, one can now get warnings when matching routes.)