Single Route File

[brillout]

Description

Being able to define the entire routing of the app in a single file.

// vike.config.h.ts

import type { Config } from 'vike/types'
import LandingPage from './pages/LandingPage.js'
import ProductListPage from './pages/ProductListPage.js'
import ProductPage from './pages/ProductPage.js'

export default {
  pages: [
    '/': {
      Page: LandingPage
    },
    '/product/@id': {
      Page: ProductPage
    },
    '/products': {
      Page: ProductListPage
    },
    // ...
  ]
} satisfies Config

If you want this, feel free to write a comment down below explaining why. The more we know why users want this, the better we can prioritize accordingly.

[brillout]

@doeixd You're right and that's the plan: https://vite-plugin-ssr.com/extends. (The rudimentary Single Route File implementation I mentioned earlier needed for the V1 design is actually precisely for enabling extensions to define pages.)

[redbar0n]

The ideal, imho, would be to have:

• A single file for routes.
• Glob import filesystem routes in the top of the single routes file based on a conventional file naming pattern (like suggested in https://github.com/brillout/vite-plugin-ssr/issues/578#issuecomment-1692994364 ). So you don’t have to type out all the basics which can be derived from the file system by simple convention (less overhead / more DRY / convention over configuration).
• Being able to override the imported filesystem routes for specific cases. Retains full power of configuration since done in JS (no need for fancy file name patterns / extensions in the file system). But being able to quickly get an overview of these overrides in a central place.
• No need to navigate through the file system to find potentially overriding route config files for specific paths. Less config files gives less clutter and better overview.

Thumbs up or heart if you like or love this ideal.

Update: Another thing I thought of is that it would be very nice to have the Vike code for parsing the filesystem routes available in a file (not buried deep within some framework code). So you could easily override it if you wanted to parse the filesystem routes differently (if you wanted a different project folder structure for instance).

[brillout]

@redbar0n

Each + file can live in a different environment which was a primary motivation for the V1 design; some of your ideas aren't implementable without code extraction (wich I believe to be an anti-pattern).

As for increased flexibility around Filesystem Routing I agree that'd be nice, but it isn't a priority at the moment. That said, I'm happy to revisit prioritisation upon blockers and/or sponsoring.

[brillout]

Latest design for defining all routes in a single file: https://github.com/vikejs/vike/issues/341#issue-1274652261.

[redbar0n]

some of your ideas aren't implementable without code extraction

I presume you mean «Code Extraction: The act of separating the code and creating server and client code bundles». But doesn’t Vike already do this to an extent?

If the problem with having all routes in a single file is that client side routing and server side routing would need to be extracted from that file, what about 2 files: a single route file for the client, and a single route file for the server? Could make it clearer. E.g. So if you want to SSR a particular page you’d move it to the single route file for the server.

[brillout]

@redbar0n I'm afraid it isn't that simple. In general, design needs an holistic understanding of a lot of problems at once. I'd be happy to elaborate but that would require 2-3 pages of text. As you can imagine, prioritization is crucial for Vike to grow.

That said, it's paramount that users communicate their pain points and what they try to achieve (the goals), and I'm more than happy to hear (critical) feedback here. The resulting design (how to achieve the goals) is a work that only Vike maintainers can do.