E2E test should use the local version

[belgattitude]

Before this PR our e2e tests and example install were using the last published version on npm.

This defeats the CI confidence.

As not everything is perfect, I haven't been able to simply use the npm link:../.. protocol to create a symlink to the root (where the dist folder resides). The main reason is:

Code like this:

next-i18next/src/serverSideTranslations.ts

Lines 26 to 29 in 0c796cb

	if (!userConfig && fs.existsSync(path.resolve(DEFAULT_CONFIG_PATH))) {
	userConfig = await import(path.resolve(DEFAULT_CONFIG_PATH))
	}

Will be transpiled by babel (cjs) to this

 return Promise.resolve("".concat(_path["default"].resolve(DEFAULT_CONFIG_PATH))).then(function (s) {
              return _interopRequireWildcard(require(s));
            });

And it won't work in a webpack context: require(s) will fail in some situations. (I've tested a lot of options, like webpackIgnores...). Changing this is a significant work and is prone to errors (webpack have limits). Example of error:

Error occurred prerendering page "/en". Read more: https://nextjs.org/docs/messages/prerender-error
Error: Cannot find module '/home/sebastien/github/next-i18next/examples/simple/next-i18next.config.js'

See also #1917 (comment) and this https://github.com/bryantobing12/layout-reproduce-i18next/pull/1/files#diff-b09c1f3451013e7a5ceffec2636d3175563b96a911a9a91c1fe08d5110a7a1b0

My opinion (for the future):

@adrai FYI: We shouldn't play with that and always require the consuming code to provide the config (especially next 13 turbopack, etc). For example appWithTranslation and serverSideTranslations must receive the config file path. Otherwise it won't work (in monorepo situations for example). There's options to do so (like creating a new method for ssr and make the second parameter of appWithTranslation required).

In order to move forward, I'll let this for a later time.

PS: This P/R introduce more complexity for the examples. But I feel for now it's a good trade-off. I don't think people will use blindly our package.json as is (with the file:../...). The gain for us is quality.

[belgattitude]

@adrai before merging I would like your opinion on this.

TLDR: we make examples a bit dirty, we gain confidence on CI.

[belgattitude]

Dirty part 😮‍💨 till better options emerges.

[belgattitude]

This makes the example less copy/pastable. But I don't think devs would use our package.json as is when looking at the example.

[adrai]

@adrai before merging I would like your opinion on this.

TLDR: we make examples a bit dirty, we gain confidence on CI.

I think i can live with that.

[belgattitude]

Thanks I'll merge and continue a bit tomorrow. Just want to be sure the current master has no regression. I'll ping when I'm confident.