`@google-cloud/tasks` 4.1.0 causes cloud_tasks_client_config.json `no such file or directory` (publish esm)

[Xennis]

The following error happens with @google-cloud/tasks after updating from 4.0.1 to 4.1.0:

Error: ENOENT: no such file or directory, open '/vercel/path0/fuu/node_modules/.pnpm/@google-cloud+tasks@4.1.0_encoding@0.1.13/node_modules/@google-cloud/tasks/build/esm/src/v2/cloud_tasks_client_config.json'
    at Object.openSync (node:fs:603:3)
    at Object.readFileSync (node:fs:471:35)
    at 64300 (/var/task/fuu/.next/server/app/app/api/site/route.js:1:1998)
    at t (/var/task/fuu/.next/server/webpack-runtime.js:1:143)
    at __webpack_exec__ (/var/task/fuu/.next/server/app/app/api/route.js:57:72254)
    at /var/task/fuu/.next/server/app/app/api/route.js:57:72374
    at t.X (/var/task/fuu/.next/server/webpack-runtime.js:1:1285)
    at /var/task/fuu/.next/server/app/app/api/route.js:57:72340
    at Object.<anonymous> (/var/task/fuu/.next/server/app/app/api/route.js:57:72435)
    at Module._compile (node:internal/modules/cjs/loader:1256:14) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: '/vercel/path0/fuu/node_modules/.pnpm/@google-cloud+tasks@4.1.0_encoding@0.1.13/node_modules/@google-cloud/tasks/build/esm/src/v2/cloud_tasks_client_config.json',
  page: '/app/api/sync'
}

This seems to be related to the only change with was made from from version 4.0.1 to version 4.1.0: #4720

Environment details

• which product (packages/*): @google-cloud/tasks
• Node.js version: 18
• npm version: pnpm

Steps to reproduce

[sofisl]

As a workaround, I've republished the 'latest' tag as 4.0.1. This should have been released as a breaking change. Please re-install the package at latest, it should work.

[Xennis]

Thanks. I already downgraded to version 4.0.1 and can confirm with that version it works again. Looking forward to a proper new version then :-)

[sofisl]

Could I trouble you for the code that failed? Thank you in advance.

[Xennis]

Hey @sofisl ,

sure. It creates a new task:

Edited afterwards: Added import line

import { CloudTasksClient } from "@google-cloud/tasks"

const tasksClient = new CloudTasksClient({
  projectId: process.env.GCP_TASKS_PROJECT_ID,
  credentials: {
    client_email: process.env.GCP_TASKS_CLIENT_EMAIL,
    private_key: process.env.GCP_TASKS_PRIVATE_KEY,
  },
})

// ...

    const taskBody = { full: body?.full === "yes" }
    await tasksClient.createTask({
      parent: process.env.GCP_TASKS_PARENT,
      task: {
        httpRequest: {
          httpMethod: "POST",
          url: "https://...<my-url-here-which-I-removed>",
          // See https://github.com/googleapis/nodejs-tasks/issues/606#issuecomment-1194074190 why encoding is needed
          body: Buffer.from(JSON.stringify(taskBody)).toString("base64"),
          oidcToken: {
            serviceAccountEmail: process.env.GCP_TASKS_ACCOUNT_EMAIL,
          },
        },
      },
    })

[sofisl]

Thank you! Could you include how you import the library?

[Xennis]

Hey @sofisl ,

import { CloudTasksClient } from "@google-cloud/tasks"

The application is a Next.js application. The package manager is pnpm and the build command next build.

[AntQwanlity]

Having this issue after migration to 5.0
Reverting back to forced 4.0.1 fixes the issue

[felixmpaulus]

Downgrading fixed it. Well that's 7h of troubleshooting for you. Glad I found this thread!

[wangii]

2 hours of my life spent on being frustrated. but anyway, thanks!

[andyjy]

The ESM refactor introduced a layer of indirection for importing the JSON files, replacing require() with a combination of readFileSync() with a path computed via an expression, which together prevent the JSON files from being picked up by bundler tracing and included when bundling using setups like Next.js.

Importing JSON without readFileSync() is possible in latest Node.js but requires experimental JSON imports enabled in earlier versions. I attempted to experiment with module.createRequire() for ESM but this didn't appear to fix tracing with @vercel/nft (as used by Next.js). The ideal solution may well be to convert the JSON files to a javascript object export, which would enable them to be imported and bundled/traced as normal.

cc: @sofisl as I see this issue was closed as "completed" without context, but still persists (specifically broken bundled ESM builds). Thanks!

[sofisl]

Closed this because at the time, the release was accidental, it should have been released as a breaking change. Reopening because it seems like it's still an issue with the 5.0.0 release.