Can you share a failing test case?

/Pages
  parent.vue
  /parent
    child.vue

In this situation, the routing table looks like:

[
  { 
    path: "/parent",
    children: [
      { path: "child" } 
    ]
  }
]

Doing a simple route.path = route.path on the child route will report the warning.

The warning is actually correct: currently, only absolute paths are supported. Ideally, setting the path should work with both absolute and non-absolute paths, but that hasn't been implemented yet. Contribution welcome!

@posva can you explain a little more where the problem lies? I don't get it.
For nested child routes, paths are relative by default and they work.
How is path.route = path.route not idempotent?
Where would something break if I set a nested child path to a relative value, whereas the default relative path actually works?

It’s because in the build-time hooks to change routes you don’t get access to the route records, you get access to an editable tree node that then gets serialized into a route tree. Therefore some operations are different

ok.
It's very surprising and unintuitive that what you read (get route() on the record returns the relative path) does not match the semantics of what you write (set route("..") on the record can't be relative?). I think it'd be worthwhile thinking about how this could be improved.

I suppose a work-around for the time being is building and assigning the full absolute path of the child route. With a bit of glue code it can be done (walk up the parents routes and merge them, being careful if they are relative or absolute).

Yeah, it’s not intuitive. It will be improved sooner or later

Just for context, I believe the issue comes from the differences between the meaning of path in different contexts. Here's an example in the TreeNode class:

https://github.com/posva/unplugin-vue-router/blob/main/src/core/tree.ts

  /**
   * Returns the route path of the node without parent paths. If the path was overridden, it returns the override.
   */
  get path() {
    return (
      this.value.overrides.path ??
      (this.parent?.isRoot() ? '/' : '') + this.value.pathSegment
    )
  }

  /**
   * Returns the route path of the node including parent paths.
   */
  get fullPath() {
    return this.value.overrides.path ?? this.value.path
  }

You can see that the override is actually overriding the whole path not just the pathSegment.

Just chiming in on this because I've reviewed our applications again.

To provide context: what we'd like to do is simply force a kebab-case convention on URLs, although our folders could be PascalCase, and similar deviations. Just think path = path.toLowerCase().

Digging into the code again, maybe all we need is to manipulate route.node.value.pathSegment which is what get path() on EditableTreeNode ends up using to build a full path. (I understand I'm not supposed to reach into internals like this, but hey that's JS 😁)

Generally this seems to be a very inconsistent topic as:

• When using a <route> block or definePage we get warning if we specify relative paths,
• Yet the convention based on file names is all relative paths.

In fact, when I look at the generated auto-routes file, I see this:

{
    path: 'news', /* <-- RELATIVE ALL THE WAY TO BROWSER! */
    name: '/Admin/System/news',
    component: () => import("/Modules/Admin/System/news.page.vue"),
    /* no children */
    meta: { /*...*/ }
}

Hopefully if #519 can be merged this will be more flexible.

Thanks for the feedback and the PRs (@robertmoura @jods4). This really helps to understand cases I didn't think about in the first place.

I'm still a bit swamped with other stuff at the moment so I will come back to this later, hopefully in January and do a big pass with other HMR improvements and more data loaders API.