[🐛 Bug]: import { getRequestContext } from "@cloudflare/next-on-pages"; not working as expected

[coratype]

next-on-pages environment related information

npx @cloudflare/next-on-pages --info

System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 CPU: (10) arm64 Apple M1 Pro Memory: 16 GB Shell: /bin/zsh Package Manager Used: npm (8.19.2)

Relevant Packages: @cloudflare/next-on-pages: 1.11.0 vercel: N/A next: N/A

Description

i'm trying to initiate the new setupDevPlatform() functionality, i have installed @cloudflare/next-on-pages via npm install as a dependency, however i seem to be getting an error when trying to import it.

Reproduction

No response

Pages Deployment Method

None

Pages Deployment ID

No response

Additional Information

No response

Would you like to help?

• [ ] Would you like to help fixing this bug?

[coratype]

this bug was my last straw with cloudflare. i really wanted to just keep everything under cloudflare and migrate my nextjs app over but i have spent countless days fighting against the development experience with cloudflare. the documentation for one has a hundred different variations on how to access the ENV variable in server routes. it also has several different variations on how to structure the routes. in some cases, the former doesnt even work. there are different configuration files you have to set up, for both local and production. there are specific things you have to include inline when running commands. there are types you have to setup manually within the configuration files which again there are several different versions of. its genuinely really annoying to keep track of, and i hope eventually one day cloudflare learns to just simplify things as well as vercel has because as much as i prefer to use cloudflare, vercel truly is one click deploy (although im not using vercel anymore either).

[dazweeja]

Does @cloudflare/next-on-pages appear in your package.json?

[coratype]

yes but i’ve since given up on cloudflare i’m hosting on a VPS now

[jebadirad]

+1 on this. I am also having a lot of issues with cloudflare next on pages, and this is my latest issue im trying to fight

[dario-piotrowicz]

Hi @coratype, thanks for the issue and sorry for the late reply 🙇

I've tested this in a new application created using C3 and it seems to be working as expected:

I've also created a brand new npm project (npm init), installed next-on-pages and typescript and the types there also seem to work as intended:

Granted I had to update the boilerplate tsconfig file to use the correct module resolution in this case:

From your screenshot I can't tell if you might also be hitting this issue 🤔

Anyways things seem to be working ok on my side, I'd really appreciate more details on how this is not working on your side 🙂 (ideally a minimal reproduction would be great!)

[dario-piotrowicz]

this bug was my last straw with cloudflare. i really wanted to just keep everything under cloudflare and migrate my nextjs app over but i have spent countless days fighting against the development experience with cloudflare.

I'm so sorry to hear this :sweat: , hopefully we'll manage to improve what you're pointing our here and win you back in the future :sweat:

the documentation for one has a hundred different variations on how to access the ENV variable in server routes.

the only documentation that we should include is using getRequestContext, what other variations did you find? (using process.env? that was the previous suggested method, hopefully that should not really be present in our documentation)

it also has several different variations on how to structure the routes. in some cases, the former doesnt even work.

I am not sure I understand this criticism, could you elaborate? :pray:

there are different configuration files you have to set up, for both local and production.

Yes I agree... (I'm assuming that you're referring to the config files for env variables?) there's wrangler.toml and .dev.vars for env variables and secrets, these are also incompatible with env files so you might need to set the latter for running next dev and the former for running wrangler pages dev

This is something that I've already flagged internally multiple times and something that we can hopefully try to address in the near future (but it is more of a wrangler problem and not something specific to next-on-pages).

there are specific things you have to include inline when running commands.

This (assuming that you're referring to the flags you needed to pass to wrangler pages dev) is actually no longer needed as we've added Pages support for the config file: https://developers.cloudflare.com/pages/functions/wrangler-configuration/ (so as long as you use a proper wrangler.toml you should not need (or at least not as much) to provide any flags to the wrangler pages commands as those should pick up the config from the toml file instead)

there are types you have to setup manually within the configuration files which again there are several different versions of.

Again I am not sure I follow :sweat:

its genuinely really annoying to keep track of, and i hope eventually one day cloudflare learns to just simplify things as well as vercel has because as much as i prefer to use cloudflare, vercel truly is one click deploy (although im not using vercel anymore either).

Yes I agree that we introduce lots of features and that it might be hard to keep track of them and new apis/configs, we do try to streamline things as much as possible and provide a good DX, but we also don't want to break developers so we often can't simply remove (/simplify) things

Anyways thank you very much, I do appreciate the feedback although it's not really very positive :sweat:

if you let me know what documentation issues you were facing I think those should be pretty simple to address, for the rest as I mentioned there are things that we've already addressed and/or we know of and plan on addressing in the future, in any case I'm always happy to hear suggestions/feedbacks on how we can improve things :slightly_smiling_face: (but as I mentioned, for backward compatibility issues and other similar concerns it's not always possible to go certain directions)

[stephen-risk-first]

I have the same issue in my project. The error message for me is the same as @dario-piotrowicz has provided in the image, the one that guides you toward using a more modern value for moduleResolution within your TS configuration. This doesn't really appear to be an option for me though, when I switch to using Node16/NodeNext then I get a tonne of errors popping up for other things.

Surely there must be a way to publish the types for @cloudflare/next-on-pages in a way that is compatible with Node module resolution?

[alienkarma]

I am facing the same issue still. I managed to bypass the error for local development using polyfill but the problem remains on deployment. This is the error I get on deployment:-

20:24:15.096 | Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in /opt/buildhome/repo/node_modules/@cloudflare/next-on-pages/package.json 20:24:15.097 | at new NodeError (node:internal/errors:405:5) 20:24:15.097 | at exportsNotFound (node:internal/modules/esm/resolve:359:10) 20:24:15.097 | at packageExportsResolve (node:internal/modules/esm/resolve:639:13) 20:24:15.098 | at resolveExports (node:internal/modules/cjs/loader:567:36) 20:24:15.098 | at Function.Module._findPath (node:internal/modules/cjs/loader:636:31) 20:24:15.098 | at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1063:27) 20:24:15.098 | at Function.Module._resolveFilename.sharedData.moduleResolveFilenameHook.installedValue [as _resolveFilename] (/opt/buildhome/repo/node_modules/@cspotcode/source-map-support/source-map-support.js:811:30) 20:24:15.098 | at Function.Module._load (node:internal/modules/cjs/loader:922:27) 20:24:15.098 | at Module.require (node:internal/modules/cjs/loader:1143:19) 20:24:15.098 | at require (node:internal/modules/cjs/helpers:121:18) { 20:24:15.098 | code: 'ERR_PACKAGE_PATH_NOT_EXPORTED' 20:24:15.098 | }

I am also attaching my tsconfig.json for reference as well just in case:-

{
  "compilerOptions": {
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "paths": {
      "@/*": ["./src/*"]
    },
    "forceConsistentCasingInFileNames": true
  },
  "include": [
    "env.d.ts",
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts"
  ],
  "exclude": ["node_modules"],
  "ts-node": {
    "compilerOptions": {
      "module": "commonjs"
    }
  }
}

[alienkarma]

This is unrelated to the issue thread, but wanted to post an alternate solution if nothing else works for some of you.

I created a wrapper function based on Cloudflare's API that you can use to directly read/write to the KV store.

https://www.npmjs.com/package/cloudflare-kv-wrapper