Not portable types

[sohrab-]

When using various functions, we instantiate variables that do not seem to have a portable inferred type.

For example:

export const { Link, redirect, usePathname, useRouter } =
  createSharedPathnamesNavigation({
    locales,
    localePrefix,
  });

results in

The inferred type of 'Link' cannot be named without a reference to '../node_modules/next-intl/dist/types/src/shared/types'. This is likely not portable. A type annotation is necessary.ts(2742)
The inferred type of 'useRouter' cannot be named without a reference to '../node_modules/next-intl/dist/types/src/navigation/react-client/useBaseRouter'. This is likely not portable. A type annotation is necessary.ts(2742)

Similarly,

const requestConfig = getRequestConfig(
  async ({ locale }) => { ...  }
);

results in

The inferred type of 'requestConfig' cannot be named without a reference to '../../node_modules/.pnpm/[email protected][email protected]/node_modules/use-intl/dist/types/src/core/TimeZone'. This is likely not portable. A type annotation is necessary.ts(2742)
The inferred type of 'requestConfig' cannot be named without a reference to './node_modules/next-intl/dist/types/src/server/react-server/getRequestConfig'. This is likely not portable. A type annotation is necessary.ts(2742)

For the latter, I seem to be able to get rid of it by typing it as ReturnType<typeof getRequestConfig> but the former is not as easily resolved.

Do the next-intl packages need to export these additional types, e.g. AllLocales, TimeZone, etc.? Or am I doing something wrong here?

[amannn]

Can you share your tsconfig.json or ideally a full reproduction in a bug report?

[thebossjon]

TypeScript/issues/47663

[sohrab-]

Here are my ts configs. I am working on a brand new Next.js app with just standard setup of next-intl.

// tsconfig.json
{
  "extends": "@repo/typescript-config/nextjs.json",
  "compilerOptions": {
    "plugins": [
      {
        "name": "next"
      }
    ]
  },
  "include": [
    "next-env.d.ts",
    "next.config.js",
    "**/*.js",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts"
  ],
  "exclude": ["node_modules"]
}

// @repo/typescript-config/nextjs.json
{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Next.js",
  "extends": "./base.json",
  "compilerOptions": {
    "plugins": [{ "name": "next" }],
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "allowJs": true,
    "jsx": "preserve",
    "noEmit": true,
    "paths": {
      "@ui/*": ["../../packages/ui/src/*"]
    }
  }
}

// @repo/typescript-config/base.json
{
  "$schema": "https://json.schemastore.org/tsconfig",
  "display": "Default",
  "compilerOptions": {
    "declaration": true,
    "declarationMap": true,
    "esModuleInterop": true,
    "incremental": false,
    "isolatedModules": true,
    "lib": ["es2022", "DOM", "DOM.Iterable"],
    "module": "NodeNext",
    "moduleDetection": "force",
    "moduleResolution": "NodeNext",
    "noUncheckedIndexedAccess": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strict": true,
    "target": "ES2022"
  }
}

I'll submit a bug report the first chance I get.

[amannn]

I've isolated the issue to "declaration": true. If you remove that, the error should be gone. Note that this option isn't set by default in a new Next.js app.

If there's anything that next-intl can do to be more compatible with this config option I'd generally be open to discuss, but as far as I understand, this setting is rather intended to be used in libraries rather than apps.

Hope this helps!

[sohrab-]

Thanks for that.

Yeah, it is odd coz they do seem to set it in turborepo starter.

I haven't personally groked this to figure out what changes would be required to make sure this works while leaving the declaration option on.

[MrMilan]

I recently migrated my Next.js project to Turborepo and encountered the same issue. I wasn't sure what was causing it and whether it was a valid problem.
Thanks a lot for explanation and solution.

[vaishnavi-jadhav-amla]

@sohrab- iam facing the same issue and Iam also using turorepo. Were you able to find any solution. I encountered this issue while using getRequestConfig option. Although it worked by removing the declaration option. But wanted to understand, is this the right way

[ol-ts]

What if you can't set declaration to false?
We reference some packages in our tsconfig and use
"compilerOptions": {"composite": true} which sets the declaration to true. So we can't have both composite: true and declaration: false as these two options are incompatible.