adding next-logger to develop script causes memory issues

[nicholas-c]

Fairly standard Next.js application, when adding next-logger as a NODE_OPTION to development script it causes memory leaks in relation to source maps.

"dev": "NODE_OPTIONS='-r next-logger' next dev -p 3000",

Only thing I'm doing different from standard implementation in the docs is I'm creating the Pino logger instance elsewhere and importing fully as follows, which allows me to use the same instance elsewhere in services etc. This imports the defaultConfig directly instead of being passed so I don't have to new up two separate instances of Pino (Not sure if that makes any difference)

const pino = require('pino');
const defaultConfig = require('next-logger/lib/defaultPinoConfig');

const config = {
    ...defaultConfig,
    level: process.env.LOG_LEVEL ?? 'info',
    ...(process.env.NODE_ENV === undefined
        ? {
              transport: {
                  target: 'pino-pretty',
                  options: {
                      colorize: true,
                      ignore: 'pid,hostname',
                  },
              },
          }
        : {}),
};

const logger = pino(config);

module.exports = logger;

[devinrhode2]

Not sure how you are getting an error related to WebAssembly/wasm. Maybe next is now doing some super fancy stuff, and the code handling NODE_OPTIONS is now prone to breaking in this specific way?

Mentioned in another issue - I have a fork which (with a few changes) could work with next's standalone build feature, not need the NODE_OPTIONS flag, and could therefore potentially fix your memory issue

See this comment and discussion above it: https://github.com/atkinchris/next-logger/issues/13#issuecomment-1179305621

[atkinchris]

@nicholas-c - do you have a reproducible example you can share? As @devinrhode2 says, I'm not sure how WASM is popping up here.

[atkinchris]

I'm closing this pending a reproducible example.

[rohit-gohri]

I'm also noticing this issue of next consuming too much memory since I tired to enable 'pino-pretty' transport, doesn't cause any problems without it

Will try to create reproducible small example

[Jokinen]

@rohit-gohri We might have ran into the same issue with pino-pretty. I opened a new issue (https://github.com/sainsburys-tech/next-logger/issues/51) about it in case this issue was dedicated to the WebAssembly issue.