fix(BREAKING-CHANGE): remove support migration from pages to app router

[aralroca]

Fixes aralroca/next-translate#1166

Introducing that people could partially migrate from pages to app router was a bad idea because Next.js does not support it. Just introducing i18n in the configuration breaks the app router, I'm sorry to say, but the only way to fix it from the library is to remove the migration support, then pages and app router work, but it will no longer work to use both at the same time.

[i2gor87]

I just tried to install this canary version in hopes this would fix this issue aralroca/next-translate#1173 , but seems like it breaks things:

✓ Ready in 1722ms
 ⨯ Module not found: Error: Can't resolve 'next-translate-plugin/loader' in '/Users/...'
 ⨯ ./:5:0
Module not found: Can't resolve 'next-translate-plugin/loader'
  3 |       "/not-found",
  4 |       function () {
> 5 |         return require("./node_modules/next/dist/client/components/not-found-error.js");
  6 |       }
  7 |     ]);
  8 |     if(module.hot) {

https://nextjs.org/docs/messages/module-not-found
 ⨯ ./:5:0
Module not found: Can't resolve 'next-translate-plugin/loader'

https://nextjs.org/docs/messages/module-not-found
 ○ Compiling /_error ...
 ⨯ Error: ENOENT: no such file or directory, open '/Users/.../.next/fallback-build-manifest.json'
    at readFileSync (node:fs:453:20)
    at loadManifest (/Users/.../node_modules/next/dist/server/load-manifest.js:30:54)
    at loadManifestWithRetries (/Users/.../node_modules/next/dist/server/load-components.js:34:51)
    at async loadDefaultErrorComponentsImpl (/Users/.../node_modules/next/dist/server/load-default-error-components.js:30:24)
    at async DevServer.getFallbackErrorComponents (/Users/.../node_modules/next/dist/server/dev/next-dev-server.js:579:16)
    at async DevServer.renderErrorToResponseImpl (/Users/.../node_modules/next/dist/server/base-server.js:2122:40)
    at async DevServer.pipeImpl (/Users/.../node_modules/next/dist/server/base-server.js:909:25)
    at async NextNodeServer.handleCatchallRenderRequest (/Users/.../node_modules/next/dist/server/next-server.js:225:21)
    at async DevServer.handleRequestImpl (/Users/.../node_modules/next/dist/server/base-server.js:805:17) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/Users/.../.next/fallback-build-manifest.json'
}
Error: ENOENT: no such file or directory, open '/Users/.../.next/fallback-build-manifest.json'
    at readFileSync (node:fs:453:20)
    at loadManifest (/Users/.../node_modules/next/dist/server/load-manifest.js:30:54)
    at loadManifestWithRetries (/Users/.../node_modules/next/dist/server/load-components.js:34:51)
    at async loadDefaultErrorComponentsImpl (/Users/.../node_modules/next/dist/server/load-default-error-components.js:30:24)
    at async DevServer.getFallbackErrorComponents (/Users/.../node_modules/next/dist/server/dev/next-dev-server.js:579:16)
    at async DevServer.renderErrorToResponseImpl (/Users/.../node_modules/next/dist/server/base-server.js:2122:40)
    at async DevServer.pipeImpl (/Users/.../node_modules/next/dist/server/base-server.js:909:25)
    at async NextNodeServer.handleCatchallRenderRequest (/Users/.../node_modules/next/dist/server/next-server.js:225:21)
    at async DevServer.handleRequestImpl (/Users/.../node_modules/next/dist/server/base-server.js:805:17) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/Users/.../.next/fallback-build-manifest.json'
}
Error: ENOENT: no such file or directory, open '/Users/.../.next/fallback-build-manifest.json'
    at readFileSync (node:fs:453:20)
    at loadManifest (/Users/.../node_modules/next/dist/server/load-manifest.js:30:54)
    at loadManifestWithRetries (/Users/.../node_modules/next/dist/server/load-components.js:34:51)
    at async loadDefaultErrorComponentsImpl (/Users/.../node_modules/next/dist/server/load-default-error-components.js:30:24)
    at async DevServer.getFallbackErrorComponents (/Users/.../node_modules/next/dist/server/dev/next-dev-server.js:579:16)
    at async DevServer.renderErrorToResponseImpl (/Users/.../node_modules/next/dist/server/base-server.js:2122:40)
    at async pipe.req.req (/Users/.../node_modules/next/dist/server/base-server.js:1975:30)
    at async DevServer.pipeImpl (/Users/.../node_modules/next/dist/server/base-server.js:909:25) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/Users/.../.next/fallback-build-manifest.json'
}
 ⨯ ./:1:0
Module not found: Can't resolve 'next-translate-plugin/loader'

https://nextjs.org/docs/messages/module-not-found

I replaced actual paths, but you get the idea

[aralroca]

@i2gor87 it was a problem generating the npm tarball. In 3.0.0-canary.2 the tarball is generated correctly. I hope now it works

[abriginets]

I am a little confused by your comment on this pull request.

Introducing that people could partially migrate from pages to app router was a bad idea because Next.js does not support it

But it actually does and was working perfectly fine until I tried adding translations. Which brings me to the question "why". If we look at Regarding routing section of next-translate's documentation, it clearly states

...we have chosen not to re-implement this functionality, as we aim to be a library for translating pages, rather than routing them

While next-translate does not act as the routing library, it does depend on routing features of NextJS. Which kind of leads me to asking myself a question. What would happen if next-translate abandon the idea of depending on i18n property fundamentaly? We use the library not because it can "inject" translations into the page, but because of it's tooling. We could import translations and pass them down to the page through props all by ourselves without affecting bundle sizes. So the final questions would be

1. Would that be possible to drop the use of i18n property entirely and use middleware for routing instead (which is actually suggested by NextJS representative i18n: Incremental migration to app results in 404 not found page vercel/next.js#57704 (comment)) while keeping the same API?
2. If not, what would be your suggestion on what developers should do next? Should we look for another translations library that supports both app and pages dir? Should we try to get more attention for this issue and ask for a workaround from nextjs development team?