Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After building 'unable to determine transport target for "@axiomhq/pino"' due to "cjs" folder being deleted after build #1964

Open
AliD201 opened this issue May 4, 2024 · 10 comments

Comments

@AliD201
Copy link

AliD201 commented May 4, 2024

Hello !
thanks for the great package!

I have been trying to connect to axiom and send logs. while in development everything works fine.
but in deployment I keep receiving the follwoing error

unable to determine transport target for "@axiomhq/pino"
  at fixTarget (J:\...redecated...\.output\server\node_modules\pino\lib\transport.js:146:13)
  at Function.transport (J:\...redecated...\.output\server\node_modules\pino\lib\transport.js:116:22)

am using Nuxt3 with vite.
I did try to turn off treeshaking in nuxt.config.ts

  vite:{
    build:{
      rollupOptions:{
      // Exclude the package from tree shaking
      // external: ['@axiomhq']
      treeshake: false

      }
    }
  },

but still the same issue.

Here is my logger code:

import '@axiomhq/pino'
import pino from 'pino';

const logger = pino(
  { level: 'info',
    redact: {
      paths:["email","phone","mobile_number","customerMobile","TS_customer_mobile","TS_customer_email","TS_staff_member_mobile","TS_staff_member_email","user_mobile","user_email"],
      // remove: true
    }
  },
  pino.transport({
      target: '@axiomhq/pino',
      options: {
        dataset: useRuntimeConfig().axiomDataset,
        token: useRuntimeConfig().axiomToken,
        // dataset: process.env.AXIOM_DATASET,
        // token: process.env.AXIOM_TOKEN,
      },
  }
  ),
);
export {logger}

Note: it works just fine with pino-pretty. but am not sure what is happening in the building step.

i spent my whole day playing around .. and I have no clue... what is happening on the build step

Debugging the production version using this modification :

  function fixTarget (origin) {
    origin = bundlerOverrides[origin] || origin

    if (isAbsolute(origin) || origin.indexOf('file://') === 0) {
      return origin
    }

    if (origin === 'pino/file') {
      return join(__dirname, '..', 'file.js')
    }

    let fixTarget

    for (const filePath of callers) {
      try {
        const context = filePath === 'node:repl'
          ? process.cwd() + sep
          : filePath
        throw new Error(createRequire(context).resolve(origin))
        console.log(createRequire(context).resolve(origin))
        fixTarget = createRequire(context).resolve(origin)
        break
      } catch (err) {
        // Silent catch
        throw new Error(err)
        continue
      }
    }

    if (!fixTarget) {
      throw new Error(`unable to determine transport target for "${origin}"`)
    }

    return fixTarget
  }
}

shows that the @axiomhq\pino\dist\cjs\index.cjs is what it tries to use.

though in vite .cjs is depreciated and it should use .mjs
also in the build output the cjs folder is deleted and doesn't exists, which causes this error.

@mcollina
Copy link
Member

mcollina commented May 6, 2024

Thanks for reporting!

Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that.

These bundling issues are quite tricky, so if you would like to also send a PR... that would be amazing.

@Bouchtaoui
Copy link

I have the exact same problem. I'm not able to give you a reproducible example at the moment. But it's fairly simple, just make a transport object for axiom and try deploy it on netlify or vercel and. you'll see the error yourself.

I jumped from Winston to Pino because of its asynchronous logging. But it doesn't work in production, sadly enough.

@ustad-nordin
Copy link

Thanks for reporting!

Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that.

These bundling issues are quite tricky, so if you would like to also send a PR... that would be amazing.

I setup the following project to reproduce the problem:
https://github.com/ustad-nordin/axiom-error

I hope you have the time to look at it 👀

@caelinsutch
Copy link

caelinsutch commented Aug 8, 2024

Anyone figure out a workaround? When using esbuild - there's a package esbuild-plugin-pino you can use to get around this

@ustad-nordin
Copy link

Hi there,

I ended up using Axiom without Pino. I don't want to depend on too many packages. The advantage of Pino is you can easily change transport to send your logging to another service.

@astanciu
Copy link

Also seeing this issue in Vercel, using @axiomhq/pino transport. Any updates?

@dhstevev
Copy link

dhstevev commented Aug 20, 2024

Also seeing a possible? similar issue when using pino-loki + SST and Vite to deploy a remix application via lambda

unable to determine transport target for \"pino-loki\"",
  at fixTarget (file:///var/task/server.mjs:89557:17)",
  at Function.transport (file:///var/task/server.mjs:89537:26)",
  at file:///var/task/server.mjs:111426:41",
  at ModuleJob.run (node:internal/modules/esm/module_job:222:25)",
  at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)",
  at async _tryAwaitImport (file:///var/runtime/index.mjs:1008:16)",
  at async _tryRequire (file:///var/runtime/index.mjs:1057:86)",
  at async _loadUserApp (file:///var/runtime/index.mjs:1081:16)",
  at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1119:21)",
  at async start (file:///var/runtime/index.mjs:1282:23)"```

@carsonb
Copy link

carsonb commented Aug 20, 2024

Also seeing this in Vercel with NextJS.
I attempted to incorporate pino-webpack-plugin, but ran into the same issue as pinojs/pino-webpack-plugin#190
Also attempted the identified workaround in vercel/next.js#46987 (comment) but no success

The reproducible example from 2 weeks ago in #1964 (comment) matches how I am trying to use pino with a transport target

EDIT: I've added a simple import '@axiomhq/pino' in the file where I use @axiomhq/pino as a string and I'm no longer seeing the error. This is a weird one! Might be a workaround for others. I am also listing all pino related packages in my NextJS config:

module.exports = {
  experimental: {
    serverComponentsExternalPackages: [
      'thread-stream',
      'pino',
      'pino-worker',
      'pino-file',
      'pino-pretty',
      '@axiomhq/pino',
    ],
  },
}

@magnusriga
Copy link

magnusriga commented Aug 21, 2024

@carsonb I ended up getting an issue runtime, when pino was in the config.externals list. In short, it did not exist in runtime ( which is probably not that surprising, since it was excluded from the bundle).

When we pino-webpack-plugin is included, I get different errors whether pino is in config.externals and whether we are in development or production. I will continue to investigate.

@naz
Copy link

naz commented Oct 9, 2024

The import '@axiomhq/pino' fix worked for my case where I use Pino with NestJS running on Vercel environment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants