Migrating to v3.22

[omermecitoglu]

Today I noticed there are some breaking changes in v3.22 while I was trying to upgrade next-intl in a project.

I have a component like this where I pass the Link component as a prop

<LinkButton
  as={Link} // <-- this is the important part!
  icon={faMagnifyingGlass}
  href="/search-by-invoice-no"
  text={t("search-by-invoice-no")}
  size="sm"
/>

It's using these types

type LinkProps = {
  href: string,
  prefetch?: boolean,
  scroll?: boolean,
  className?: string,
  children: ReactNode,
};

type LinkButtonProps = {
  as: (props: LinkProps) => ReactNode,
  variant?: ButtonVariant,
  size?: "lg" | "sm",
  icon?: IconProp,
  href: string,
  text?: string,
  disabled?: boolean,
  stretched?: boolean,
};

It worked perfectly within the next.js ecosystem until now. But now it complains about the type of href

Types of property 'href' are incompatible.
          Type 'string' is not assignable to type '"/login" | "/register" | "/terms" | "/" | "/admin" | ({ pathname: "/login"; } & Omit<UrlObject, "pathname">) | ({ pathname: "/register"; } & Omit<UrlObject, "pathname">) | ... 13 more ... | ({ ...; } & Omit<...>)'.

First I tried to solve it by extending those types with generics. It worked. But it didn't work well with next.js' Link component.

Is there any way to disable type-safe href? or any idea to solve this?

Btw I noticed the Link composition section in the docs. But it's not an option for this case. Because this component comes from a library which is supposed to stay agnostic with next.js plugins.

[amannn]

some breaking changes in v3.22

You mean updating to createNavigation requires some changes, right? Version 3.22 is by itself just a minor version with full backwards compatibility, so you can upgrade at your own pace if desired. The upcoming v4 will eventually removed deprecated navigation APIs in favor of createNavigation though.

But in regard to your question: If you use pathnames, the Link component from createNavigation will help you to make sure that only known pathnames can be received as an href. While for simple pathnames without any params this is just a typed string, in case you support pathnames with params (e.g. /users/[userId]) this will require passing the params separately (see docs for Link).

You can compose the href prop in order to wrap Link into another component if you like. If you're not interested in this, you can of course use something like as={Link as any} or // @ts-expect-error but I'd really encourage you to try out the type-safe way.

[omermecitoglu]

I was actually planning to keep going with old api until v4. It was working in the dev server. But there were some type errors when I run next build so I decided to migrate to the new api (createNavigation)

The idea of type-safe pathnames is fascinating but however it ties me up in this situation. I think I'll do it with as as you suggested.

Thanks for your answer and also for this awesome plugin. Have a good day!

[omermecitoglu]

Today I noticed while I was migrating another project to 3.22 APIs

when pathnames is not defined in defineRouting, I don't have any type issue with Link