With generate:types, you cannot directly call revalidateTag inside Payload

[HarleySalas]

To reproduce, you can use the revalidateTag function from next.cache inside of a collection hook and then try to run generate:types. It will result in an error similar to the following:

payload generate:types

//Note the following line where it goes to the C:\ directory twice...? strange.
Error resolving path: [Error: ENOENT: no such file or directory, lstat 'C:\{redacted}\node_modules\C:\{redacted}\node_modules\.pnpm\next@14.3.0-canary.37_@babel+core@7.24.5_react-dom@18.3.1_react@18.3.1\node_modules\next\cache.js'] {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'lstat',
  path: 'C:\\{redacted}\\node_modules\\.pnpm\\next@14.3.0-canary.37_@babel+core@7.24.5_react-dom@18.3.1_react@18.3.1\\node_modules\\next\\cache.js'
}

node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
    at validateString (node:internal/validators:162:11)
    at pathToFileURL (node:url:1024:3)
    at resolve (file:///C:/{redacted}/node_modules/.pnpm/payload@3.0.0-beta.29_@swc+core@1.5.5_@swc+types@0.1.6_graphql@16.8.1_typescript@5.4.5/node_modules/payload/dist/bin/loader/index.js:76:18)
    at async nextResolve (node:internal/modules/esm/hooks:865:22)
    at async Hooks.resolve (node:internal/modules/esm/hooks:303:24)
    at async handleMessage (node:internal/modules/esm/worker:196:18) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Would be nice to double check that revalidatePath and the other next/cache functions will also not cause issues when using generate:types

payload@beta.29 next@14.3.0-canary.37

[AlessioGr]

Hey @HarleySalas I cannot reproduce it. Could you add a reproduction? Will check it out then!

[HarleySalas]

Hey @HarleySalas I cannot reproduce it. Could you add a reproduction? Will check it out then!

hoped it'd be solved in 6341, but still getting it in the latest version.

Here is the reproduction; see the Page collection. I assume you're not able to reproduce due to some sort of package version.

[HarleySalas]

I experience the same issue, adding a function which users next/headers in a field afterRead hook.

> payload generate:types

Error resolving path: [Error: ENOENT: no such file or directory, lstat 'C:\dev\projects\scene-online\node_modules\C:\dev\projects\scene-online\node_modules\.pnpm\next@14.3.0-canary.37_@babel+core@7.24.5_react-dom@18.3.1_react@18.3.1\node_modules\next\headers.js'] {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'lstat',
  path: 'C:\\dev\\projects\\scene-online\\node_modules\\C:\\dev\\projects\\scene-online\\node_modules\\.pnpm\\next@14.3.0-canary.37_@babel+core@7.24.5_react-dom@18.3.1_react@18.3.1\\node_modules\\next\\headers.js'
}

node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
    at validateString (node:internal/validators:162:11)
    at pathToFileURL (node:url:1024:3)
    at resolve (file:///C:/dev/projects/scene-online/node_modules/.pnpm/payload@3.0.0-beta.31_@swc+core@1.5.6_@swc+types@0.1.6_graphql@16.8.1_typescript@5.4.5/node_modules/payload/dist/bin/loader/index.js:75:18)
    at async nextResolve (node:internal/modules/esm/hooks:865:22)
    at async Hooks.resolve (node:internal/modules/esm/hooks:303:24)
    at async handleMessage (node:internal/modules/esm/worker:196:18) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Every time I want to generate:types, I have to go through all my code and comment out anything that uses something imported by anything from next, it seems. (just a theory)

Edit: Actually, this is kind of weird... the function that I had to comment out, which caused this issue with next/headers (based on headers being mentioned in the error)... I'm not even using next/headers for that function. I just use a function, which is imported from another file and that other file happens to have a function, which uses headers in it (getUser)

So, the mere existence of something in the same file causes the error.

Here is the file (I only import the getEmbedToken function for my collection hook:

import 'server-only'
import { getUser } from '../auth/data'
import { Upload } from 'payload-types'
import { createHash } from 'crypto'

export const getWatchVideoUrl = async (id: string) => {
  const user = await getUser()
}

export const getEmbedToken = ({ upload }: { upload: Upload }) => {
  const baseUrl = upload.video?.directPlayUrl
  const videoId = upload.video?.guid
  const securityKey = process.env.BUNNY_STREAM_TOKEN_AUTH_KEY

  if (!videoId || !baseUrl || !securityKey) {
    console.log(
      `Missing one of videoId: ${videoId}, baseUrl: ${baseUrl}, securityKey: ${securityKey}`,
    )
    return null
  }

  const expiration = Math.floor(Date.now() / 1000) + 24 * 60 * 60 //24 hrs

  const stringToHash = securityKey + videoId + expiration

  const hash = createHash('sha256')
  hash.update(stringToHash)
  const token = hash.digest('hex')

  return `${baseUrl}?token=${token}&expires=${expiration}`
}

[AlessioGr]

Hey @HarleySalas I cannot reproduce it. Could you add a reproduction? Will check it out then!

hoped it'd be solved in 6341, but still getting it in the latest version.

Here is the reproduction; see the Page collection. I assume you're not able to reproduce due to some sort of package version.

@HarleySalas I pulled down your branch, did pnpm i, then ran pnpm generate:types, and it worked perfectly

Could you do a clean install with node 22.1.0 and pnpm 8.15.7 and see if you still get this issue on that specific branch?

[HarleySalas]

@AlessioGr Switching to node 22.1.0 resolved this specific issue. I believe it's due to the improvements in ESM support though. If you guys intend to support Vercel, wouldn't it be necessary to ensure everything works in the current LTS version, as opposed to latest? I am curious; do you use nvm? Would you be willing to see if you experience the issue when using the LTS version?

[AlessioGr]

@AlessioGr Switching to node 22.1.0 resolved this specific issue. I believe it's due to the improvements in ESM support though. If you guys intend to support Vercel, wouldn't it be necessary to ensure everything works in the current LTS version, as opposed to latest? I am curious; do you use nvm? Would you be willing to see if you experience the issue when using the LTS version?

@HarleySalas Interesting! Even with node 20, I cannot reproduce the issue though. Which exact node version have you been using?

[AlessioGr]

Closing this, as the issue only happened on Node 20.5.1 (which is lower than the minimum node version) and is resolved after upgrading to node 20.11.1