Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: Cannot find module "xxx.json" #736

Closed
ManucherKM opened this issue Dec 19, 2023 · 3 comments · Fixed by #742
Closed

Error: Cannot find module "xxx.json" #736

ManucherKM opened this issue Dec 19, 2023 · 3 comments · Fixed by #742
Labels
bug Something isn't working unconfirmed Needs triage.

Comments

@ManucherKM
Copy link

Description

Hey, everybody. I have encountered a rather strange problem. When switching to an unknown "locale" the console displays 'Error: Cannot find module "xxx.json"', but the application works normally.

Error screenshot:

image

Page:

image

I apologize in advance. When trying to simulate this error in a simplified version, I failed. But if it's not a problem, here's my pet project repository: https://github.com/manucherkm/quickfile. So, how can I solve this problem? Otherwise I am happy with the package so far.

Mandatory reproduction URL (CodeSandbox or GitHub repository)

https://github.com/manucherkm/quickfile

Reproduction description

Steps to reproduce:

  1. Open the downloaded project
  2. run npm i
  3. Add a .env.local file with the contents NEXT_PUBLIC_API_URL=http://localhost:5000 and NEXT_PUBLIC_CLIENT_URL=http://localhost:3000
  4. run npm run dev
  5. Navigate to the non-existent locale /sdasda
  6. Look in the console of the IDE/Code Editor.

Expected behaviour

Expected behavior: Error-free console and working project.

What we have now: A working project, but with an error in the console.

@ManucherKM ManucherKM added bug Something isn't working unconfirmed Needs triage. labels Dec 19, 2023
@flux0uz
Copy link

flux0uz commented Dec 19, 2023

We have similar errors in our logs.

Capture d’écran 2023-12-19 à 15 58 10

With this matcher for the middleware:

export const config = {
  matcher: [
    // Skip all paths that should not be internationalized
    "/((?!api|_next|_vercel|.*\\..*).*)",
    // Match all pathnames within `users|songs|artists`, optionally with a locale prefix
    "/([\\w-]+)?/(songs|artists|users)/(.+)",
  ],
}

We use [email protected] and [email protected]

@FourwingsY
Copy link

Same error here.
I just write some workarounds for this.

export default getRequestConfig(async ({ locale }) => {
  if (!supportedLocales.includes(locale)) {
    return { messages: (await import(`./${defaultLocale}.json`)).default };
  }
  return {
    messages: (await import(`./${locale}.json`)).default,
  };
});

amannn added a commit that referenced this issue Dec 21, 2023
…and update docs to suggest validating the locale in `i18n.ts` (#742)

Users are currently struggling with errors that are caused by these two
scenarios:
1. An invalid locale was passed to `next-intl` APIs (e.g.
[#736](#736))
2. No locale is available during rendering (e.g.
[#716](#716))

**tldr:**
1. We now suggest to validate the incoming `locale` in
[`i18n.ts`](https://next-intl-docs.vercel.app/docs/usage/configuration#i18nts).
This change is recommended to all users.
2. `next-intl` will call the `notFound()` function when the middleware
didn't run on a localized request and `next-intl` APIs are used during
rendering. Previously this would throw an error, therefore this is only
relevant for you in case you've encountered [the corresponding
error](https://next-intl-docs.vercel.app/docs/routing/middleware#unable-to-find-locale).
Make sure you provide a relevant [`not-found`
page](https://next-intl-docs.vercel.app/docs/environments/error-files#not-foundjs)
that can be rendered in this case.

---

**Handling invalid locales**

Users run into this error because the locale wasn't sufficiently
validated. This is in practice quite hard because we currently educate
in the docs that this should happen in [the root
layout](https://next-intl-docs.vercel.app/docs/getting-started/app-router#applocalelayouttsx),
but due to the parallel rendering capabilities of Next.js, potentially a
page or `generateMetadata` runs first.

Therefore moving this validation to a more central place seems
necessary. Due to this, the docs will now suggest validating the locale
in `i18n.ts`. By doing this, we can catch erroneous locale arguments in
a single place before e.g. importing JSON files.

The only edge case is if an app uses no APIs of `next-intl` in Server
Components at all and therefore `i18n.ts` doesn't run. This should be a
very rare case though as even `NextIntlClientProvider` will call
`i18n.ts`. The only case to run into this is if you're using
`NextIntlClientProvider` in a Client Component and delegate all i18n
handling to Client Components too. If you have such an app, `i18n.ts`
will not be invoked and you should validate the `locale` before passing
it to `NextIntlClientProvider`.

**Handling missing locales**

This warning is probably one of the most annoying errors that users
currently run into:

```
Unable to find next-intl locale because the middleware didn't run on this request.
```

The various causes of this error are outlined in [the
docs](https://next-intl-docs.vercel.app/docs/routing/middleware#unable-to-find-locale).

Some of these cases should simply be 404s (e.g. when your middleware
matcher doesn't match `/unknown.txt`), while others require a fix in the
matcher (e.g. considering `/users/jane.doe` when using `localePrefix:
'as-necessary'`).

My assumption is that many of these errors are false positives that are
caused by the `[locale]` segment acting as a catch-all. As a result, a
500 error is encountered instead of 404s. Due to this, this PR will
downgrade the previous error to a dev-only warning and will invoke the
`notFound()` function. This should help in the majority of cases. Note
that you should define [a `not-found`
file](https://next-intl-docs.vercel.app/docs/environments/error-files#not-foundjs)
to handle this case.

I think this change is a good idea because if you're using
`unstable_setRequestLocale` and you have a misconfigured middleware
matcher, you can provide any kind of string to `next-intl` (also
`unknown.txt`) and not run into this error. Therefore it only affects
users with dynamic rendering. Validating the locale in `i18n.ts` is the
solution to either case (see above). Also in case something like
[`routeParams`](#663) gets
added to Next.js, the current warning will be gone entirely—therefore
tackling it from a different direction is likely a good idea.

The false negatives of this should hopefully be rather small as we
consistently point out that you need to adapt your middleware matcher
when switching the `localePrefix` to anything other than `always`.
Dev-only warnings should help to get further information for these
requests.

---

Closes #736
Closes #716
Closes #446
@amannn
Copy link
Owner

amannn commented Dec 21, 2023

There was an update to this in #742. The solution is pretty much what @FourwingsY is suggesting here: The locale should be validated in i18n.ts. This is now suggested in the docs moving forward.

Thanks for raising this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working unconfirmed Needs triage.
Projects
None yet
4 participants