The scope and future direction of unplugin-vue-router

[ferferga]

Hello. I'm opening this with the aim to help in shaping unplugin-vue-router and the ecosystem around vue-router, gathering feedback from other as well as @posva. I love this plugin, makes working with vue-router much nicer, and I'm very grateful for all the work all contributors poured into it. However, in my opinion, the scope/direction it has it's not the most suitable one, so I'd like to propose an shift, which hopefully simplifies development and gets this plugin out of the experimental stage earlier.

To briefly sum up my proposal: unplugin-vue-router should focus solely on type definitions generation

Key reasons:

• We already have a great plugin that performs the file-based navigation: vite-plugin-pages. By creating another plugin that duplicates part of its behaviour (as vite-plugin-pages also handles other frameworks), the community have greater risks of stagnation (In fact, I think we reached that point in some degree)
• In my experience, all bugs with unplugin-vue-router have been with the file-based navigation. I didn't fiddle with it too much, since I don't want to 100% rely on an experimental plugin for this, but I had issues with:
  * vue-router/auto and eslint-plugin-imports not recognising it as valid imports.
  * Layouts generated by using vite-plugin-layouts
  However, type generation have been always working wonderfully.
• Users who want to still manually define their routes are left in the dust. I know unplugin-vue-router needs access to the components to handle type generation (so I guess adding file-based navigation seemed the logical choice). However, if unplugin-vue-router just focused on types, it could provide more options for the type generation, instead of relying solely in the file/folder structure, assuming an specific workflow from the developer. As the popular saying goes: Don't try to bite off more than you can chew (quien mucho abarca, poco aprieta in Spanish 😜). If we chew less, we can focus better on the first goal this plugin wanted to solve: type generation.
• In my project (mid-size application I'd say), I've been using vite-plugin-pages, vite-plugin-layouts and unplugin-vue-router together without any issues, leaving unplugin-vue-router solely for the type generation without issues. This a demonstration that what I propose is already possible. This is the repository, in case you want to check.

Advantages:

• Simpler maintenance, as the scope of the plugin will be focused in strictly one goal.
• Collaboration with the rest of the community and plugins that enriches the vue-router ecosystem, instead of replacing/deprecating them.
• Simpler barrier entry. Replacing vue-router to vue-router/auto is a find & replace action in most cases, but they're a barrier of entry for newcomers when the documentation tells them to import vue-router instead of vue-router/auto (which this plugin does).
• Better DX and customization options for everybody, without any assumptions.

Thank you very much in advance.

[posva]

I appreciate the initiative and concern! Thank you

The technical background is unfortunately more complex than it seems, making some of the proposals you make not possible or create other undesirable managing issues.

It's hard and quite time consuming to correctly explain all these difference so sorry in advance by not covering all points 😓

vite plugin pages has a broader scope than this plugin and is therefore limited by it. The page extensions possibilities present in this lib cannot always be applied outside of vue-router and much further than a simple extendPages(routes[]). If I had the time and spare money to spend months contributing to other routers to bring something like this everywhere, I would gladly do it but my reality cannot be further from that 😅 . In other words, this plugin goes in a very different direction and do not replace vite-plugin-pages as a package because it has a different scope. It does replace the usage of it for vue applications (same replace word but different context and meaning).

This plugin is not only about the typed routes, it's about what I have in mind for the future of Vue Router and file-based routing plays a big role but still allows people to not use it. In fact, file based routing is an opt-in. Typed routes are part part of it though, as discussed in #127.

In my experience, all bugs with unplugin-vue-router have been with the file-based navigation

What do you mean? Do you have a practical example?

vue-router/auto and eslint-plugin-imports not recognising it as valid imports.

An example would help for this too.

Layouts generated by using vite-plugin-layouts

IIRC the library was missing handling new vue-router routes structures used by unplugin-vue-router, which is why it might not always work.

I've been using vite-plugin-pages, vite-plugin-layouts and unplugin-vue-router

This is interesting. It could surprise you from time to time with wrong types if unplugin-vue-router is not in control of the route generation though

Regarding your advantages:

• Simpler maintenance: it's actually the opposite when you completely depend on an external package to handle the main logic 😅
• Collaboration: I'm already collaborating
• Simpler barrier entry: I think the barrier entry here is as minimal as it gets, nothing simpler than replacing a package name by another (as you said)
• Better DX and customization options for everybody: this is actually also the opposite for the same reasons as the first point: the divergence of packages creates extremely frustrating bugs when updating dependencies for users

[PixelBoii]

vue-router/auto and eslint-plugin-imports not recognising it as valid imports.

An example would help for this too.

@posva I'll slide in here as I've had a similar issue - This should help reproduce it (happens on npm run lint): https://stackblitz.com/edit/vitejs-vite-tkgrdy

I appreciate that it might not be an issue with the package itself, but if you have any ideas on how this would best be solved, please do let me know. It seems to go away when you remove the @ alias, but that isn't really an option in my case:

  settings: {
    'import/resolver': {
      alias: [['@', path.join(__dirname, './src')]],
    },
  },

The package looks great anyway! Great work 🎉

[ferferga]

Hey @posva! First of all, sorry for taking so long to reply (been really busy with exams, so I stepped down quite a lot my GH activity ☺️). Thank you very much for your thorough response and taking the time to give me an overview of everything.

I wasn't looking for a technical explanation either, so don't worry about it! Given that I had a fairly good type support already with a combination of both plugins, just wanted to showcase all of these points, just in case you didn't take them into consideration when starting the project.

What do you mean? Do you have a practical example?

An example would help for this too.

IIRC the library was missing handling new vue-router routes structures used by unplugin-vue-router, which is why it might not always work.

If you don't mind, I'm going to retry doing a full migration to unplugin-vue-router again once I have some spare time (since I tried I few versions ago, I guess a lot of things have been ironed out) and, if I face any of the issues with the imports or layouts, I will open a relevant issue, so we don't mix things up and we keep everything in scope here👍.

This is interesting. It could surprise you from time to time with wrong types if unplugin-vue-router is not in control of the route generation though

What I basically did is to match the route name generation, so both plugins generated the same route names. At least for what I use it for, it works fine for me. Once I fully switch to unplugin-vue-router, maybe I discover I'm missing so much!

I only have a simple suggestion for the future to simplify the integration even more (in case it's possible): drop the /auto suffix and augment/override when possible. I'm not a bundler plugin developer, but maybe rollup's virtual imports might be useful to override them (for vite/rollup setups of course)?
Maybe right now it's a bold move since this plugin is still experimental, but once it's stabilized and this plugin becames an essential part of vue-router it might be a good breaking change to consider.

Thank you very much for all the work you do in the vue-router ecosystem.

[posva]

Thanks for the reply!

drop the /auto suffix and augment/override when possible

Back when I tested, it didn't work 😓

[ferferga]

Sounds like a good challenge I might take at some point :)

[duclet]

vue-router/auto and eslint-plugin-imports not recognising it as valid imports.

I'm running into a similar issue. The strange thing is that it works fine in my .ts files but complains that the import doesn't exists when used inside the script setup lang="ts" block.