Param 0 har been renamed pathMatch but must be provided in router object

[mikaelkarlsson-se]

Version

3.0.5

Reproduction link

https://codesandbox.io/s/k0jxq926jr?fontsize=14

Steps to reproduce

1. Click on "Navigate to one", router should work.
2. Click on "Navigate to two", "missing param for named route "myRoute": Expected "0" to be defined" will be displayed in the console

What is expected?

Providing the property pathMatch in $router.push object should be equal to providing '0' or really work instead of 0, as 0 has been renamed to pathMatch (issue #1994).

What is actually happening?

The routing breaks because of a missing property for the wildcard (0) in the route regexp.

---

I'm using v3.0.5 but it was not possible to chose in the list.

[LinusBorg]

Works fine when I change this:

{
  myParam: route.params.param,
}

to this:

{
  myParam: route.params.myParam,
}

in the route definition.

[posva]

I took a look, the path should start with / in the route config. I found some inconsistencies but, it makes sense to provide pathMatch, using 0 was never documented

[mikaelkarlsson-se]

@LinusBorg So it should be, but the "expected 0" error occurs when navigating with the second button.
@posva True with the /, seems to work anyway though but that's maybe more of a coincidence?

Anyway, in case the demo is a bit unclear. The trouble for me in my real case, is that I want to change one parameter out of three (incl 0/pathMatch) and that's really convenient to do with ...this.$route.params, myParam: 'something' but "0" isn't present as it's been renamed to pathMatch. This leads to the error or that I need to provide to "0" property manually '0': pathMatch.

Thanks for taking your time guys and have a nice weekend! :)

[adi-zz]

@mikaelkarlsson-se Take a look at #3062, I think it's the same issue. Unfortunately, based on pasva'a answer, it seems $router.push is not that flexible as we would like it (and as it would be nice) to be.

[mikaelkarlsson-se]

@adi-zz Thanks for the info. If that's the case it should be documented and this issue can be closed.

[posva]

Closing in favour of #3072