matchPath with named parameter wrongly acting like catch-all

[lucis]

Description

I'm creating the following pages:

Here, for example, the route/app/login is catched by the /:slug route.

If I change /:slug to /*, everything works fine. So, it seems like a problem with named parameters being used.

Steps to reproduce

https://codesandbox.io/s/blue-frog-b4d73?file=/gatsby-node.js

On the Home Page, we have a link to /app, that should render app.jsx but, instead, renders slug.jsx.

Expected result

To have the /app route rendered when we have a /app path, being a more specific route than /:slug.

Actual result

The /:slug route is rendered instead.

Environment

  System:
    OS: macOS 10.15.3
    CPU: (8) x64 Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.3/bin/npm
  Languages:
    Python: 2.7.16 - /usr/bin/python
  Browsers:
    Chrome: 85.0.4183.121
    Safari: 13.0.5
  npmPackages:
    gatsby: ^2.24.65 => 2.24.65
    gatsby-plugin-antd: ^2.2.0 => 2.2.0
    gatsby-plugin-typescript: ^2.4.20 => 2.4.20

[lucis]

I was playing with getMatchPaths and, indeed, /:slug will have preference over /app/*. Is there some reason behind it I'm not seeing?

[pieh]

The path ranking algorithm we use is pretty much copy of reach/router internals ( which are documented in https://reach.tech/router/ranking ).

Using example route you provided it seems like both /:slug and /app/* rank exactly the same with score of 6, which is problematic. In case of same rank we do use alphabetic order (

gatsby/packages/gatsby/src/bootstrap/requires-writer.ts

Lines 154 to 156 in 3e92795

	// if specificity is the same we do lexigraphic comparison of path to ensure
	// deterministic order regardless of order pages where created
	return a.matchPath.localeCompare(b.matchPath)

) to ensure that output order is deterministic regardless of input order, but I think root of problem is that score is the same for those 2 paths and it shouldn't? It looks like "Static segment" might need to have much more weight than it currently have.

The math happening right now:

• for /:slug: segments: [':slug'] - so +4 for segment and + 2 for it being dynamic path = 6
• for /app/*: segments: ['app', '*'] - so for app: +4 for segment and +3 for it being static and for *: -1 for "splat penalty" = 6

I think for this case it seems intuitive that /app/* should be matched and not /:slug for /app path, but the math will get murky in other scenarios (for example for /foo/bar with /:param/bar and /foo/:param paths - it would be really undefined which should match first).