☂️ Umbrella: List of potential changes for a major version

[amannn]

This is a list of ideas for API changes that we could potentially introduce in a major version:

• Replace tsc with rollup-plugin-dts in build #2049 (ideally this is non-breaking, but to be safe we could schedule it for a major version)
• Investigate if we could remove t.rich and t.markup in favor of a universal t function that works for all cases.
• Investigate if we could get rid of t.raw. It leads users to toward bad patterns that might not work with future optimizations (see Improved type-safety for `t.raw()` and improved autocomplete. #2076 (comment) for details).
• Fix casing getTimeZone (next-intl) vs Timezone (use-intl)
• Consider making NextIntlClientProvider server-only (with IntlProvider being available on the client). The environment makes a difference here and it might be to easy to get wrong. In this case, we'd also move it to next-intl/server. Not sure if the benefit is big enough though.
• Rename "middleware" in APIs to "proxy"
• Should Link that changes a locale include nofollow by default? This could help search engines avoid indexing this link while allowing us to use a safe href before hydration. Search engines should pick up localized variants from alternate links or a sitemap.
• Remove "node10" types support
• Only a loose thought for now, but I wonder if it could be helpful to return routing config from request.ts instead of passing it to a factory function like createNavigation. Really not sure yet if it's worth it, but could be something to investigate.
  • Pro's: Avoids a hook factory, for apps with mixed routing users could use import {Link} from 'next-intl/navigation' for both parts of the app, avoids Support cloneElement in RSC-rendered <Link /> (better compatibility with Radix Primitives, Base UI, asChild & friends) #1271
  • Con's: Type safety of routes would be opt-in (similar to formats), this is especially annoying for routes with dynamic params
• Should we use UTC as a default for the time zone instead of the one the server provides? A benefit might be that you get the same results locally as when deploying to a production server.
• Should we make the now argument mandatory for format.relativeTime(…) to be explicit and avoid errors?
• Once rootParams is a thing, we could consider removing the {locale} argument from getNow. Other async functions are TBD, we might want to keep it for some like getTranslations and getFormatter.
• Revisit types for receiving t in a function (ref)
• Maybe utilize useRoute for usePathname from next-intl to avoid workarounds for static/dynamic inconsistencies (see Inconsistent behavior of usePathname with static rendering during build vercel/next.js#73085)
• Globally register error handling #1285
• TS validation for pathnames to start with /${string}? See Dynamic href not supported by Next 16 App router. Localized pathnames unusable at the moment. #2168

No decision has been made on these so far, but if you have feedback about these points, please leave it here!