[RFC] Dynamic Routes

Problem

Dynamic Routes Background Dynamic routing (also known as URL Slugs or Pretty/Clean URLs) has been a long-time requested feature of Next.js. Current solutions involve placing a L7 proxy, custom server, or user-land middleware in-front of your application. None of these solutions offer a sufficiently _ergonomic_ developer experience. Additionally, users reaching for a custom server inadvertently opt-out of advanced framework-level features like per-page serverless functions. Goals 1. Leverage convention to provide URL Slug support that is easy to reason about 2. Cover a majority of use-cases observed in the wild 3. Eliminate the need of a custom server to support `/blog/:post` 4. Validate `<Link />` route transitions when possible 5. Avoid an implementation that requires a route manifest 6. Routes must be expressible through the filesystem Proposal Next.js should support named URL parameters that match an entire URL segment. These routes would be expressed via the filesystem: 1. A filename or directory name that is wrapped with `[]` would be considered a named parameter 2. Explicit route segments would take priority over dynamic segments, matched from left-to-right 3. Route parameters would be required, never optional 4. Route parameters will be merged into the `query` object (accessible from `getInitialProps` or `router` via `withRouter`) — these parameters can not be overridden by a query parameter To help understand this proposal, let's examine the following file t