fix: workaround for importing SDKs in pnpm monorepos

[disintegrator]

There's an odd interaction between pnpm/yarn monorepos and the rules next.js uses to transpile packages. The bundler under the hood should avoid certain transpilation for node_modules but I suspect that since the SDK is symlinked and the real location isn't in node_modules then it's not being treated as "vendor" code. You can sort of confirm this behavior by looking in apps/sdk-tester/.next/server/app/page.js and searching for the string packages/client-subscriptions/lib/config.js. That code shouldn't be in that bundle... Compare this with npm modules in apps/sdk-tester/.next/server/vendor-chunks which is where I would expect the SDK to end up.

My hunch is that if you were to publish the SDK to npm and install it like any other third-party package then it'll work as intended. I'll need to test this out on my end too. There might also be a way to tell Next.js to treat certain monorepos dependencies as "vendor" code.

Until then, this PR contains a quick fix that might unblock you. In my testing, the web app loaded into an error state where it was retrying several API requests and getting a 401 because I don't have API credentials on my end. This does tell me that the code is loading and running though.

I'll need to keep digging and possibly file an issue with the Next.js team.

You may need to delete .next cache folder before running the dev server.

Here's a couple of existing issues:

vercel/next.js#35412
vercel/next.js#35110

[disintegrator]

This is no longer needed. We shipped an update that removes the "type" field. If you update your CLI and generate again then you'll get the same change as in this PR.