npm-lifecycle dependency is deprecated

[Dunky13]

https://github.com/ghiscoding/lerna-lite/blob/faf9b0895f19e7d39d7021a3fca76007e6b5a279/packages/core/package.json#L58

This package is deprecated: https://github.com/npm/npm-lifecycle#note-pending-imminent-deprecation

It requires node-gyp: ^5.0.2 which required request: 2.88.0 which is deprecated as well and throwing warnings.

[ghiscoding]

I copied the code from Lerna, if you have a better way of dealing with this then please do a Pull Request with the fix/feature.

[ghiscoding]

this seems to be the same as Lerna issue #2987 and no one ever contributed a fix. I tried to take a look at it and I don't understand how to replace it, some options seems to be gone and some have different names and so it's quite confusing and I cannot do it myself. So if someone can fix it through a PR, that would be great or else it would probably stay as it is.

Basically the code used by Lerna is the following

return runScript(pkg, stage, dir, {
    config,
    dir,
    failOk: false,
    log: opts.log,
    // bring along camelCased aliases
    nodeOptions: opts.nodeOptions,
    scriptShell: opts.scriptShell,
    scriptsPrependNodePath: opts.scriptsPrependNodePath,
    unsafePerm: opts.unsafePerm,
  }).then(
    () => {
      opts.log.silly('lifecycle', '%j finished in %j', stage, pkg.name);
    },
    (err: any) => {
      // propagate the exit code
      const exitCode = err.errno || 1;

      // error logging has already occurred on stderr, but we need to stop the chain
      log.error('lifecycle', '%j errored in %j, exiting %d', stage, pkg.name, exitCode);

      // ensure clean logging, avoiding spurious log dump
      err.name = 'ValidationError';

      // our yargs.fail() handler expects a numeric .exitCode, not .errno
      err.exitCode = exitCode;
      process.exitCode = exitCode;

      // stop the chain
      throw err;
    }
  );

while the new run-script is the following

const runScript = require('@npmcli/run-script')

runScript({
  // required, the script to run
  event: 'install',

  // extra args to pass to the command, defaults to []
  args: [],

  // required, the folder where the package lives
  path: '/path/to/package/folder',

  // optional, defaults to /bin/sh on unix, or cmd.exe on windows
  scriptShell: '/bin/bash',

  // optional, defaults to false
  // return stdout and stderr as strings rather than buffers
  stdioString: true,

  // optional, additional environment variables to add
  // note that process.env IS inherited by default
  // Always set:
  // - npm_package_json The package.json file in the folder
  // - npm_lifecycle_event The event that this is being run for
  // - npm_lifecycle_script The script being run
  // The fields described in https://github.com/npm/rfcs/pull/183
  env: {
    npm_package_from: 'foo@bar',
    npm_package_resolved: 'https://registry.npmjs.org/foo/-/foo-1.2.3.tgz',
    npm_package_integrity: 'sha512-foobarbaz',
  },

  // defaults to 'pipe'.  Can also pass an array like you would to node's
  // exec or spawn functions.  Note that if it's anything other than
  // 'pipe' then the stdout/stderr values on the result will be missing.
  // npm cli sets this to 'inherit' for explicit run-scripts (test, etc.)
  // but leaves it as 'pipe' for install scripts that run in parallel.
  stdio: 'inherit',

  // print the package id and script, and the command to be run, like:
  // > somepackage@1.2.3 postinstall
  // > make all-the-things
  // Defaults true when stdio:'inherit', otherwise suppressed
  banner: true,
})
  .then(({ code, signal, stdout, stderr, pkgid, path, event, script }) => {
    // do something with the results
  })
  .catch(er => {
    // command did not work.
    // er is decorated with:
    // - code
    // - signal
    // - stdout
    // - stderr
    // - path
    // - pkgid (name@version string)
    // - event
    // - script
  })

there seems to be a lot of changes between the 2, I mean it's not clear what is what and what is dropped. If someone can shed some light that would be great.

[fyyyyy]

Oh my theres such a mountain of stuff do sanitize lerna. We are looking for alternative tools at the moment. This project looks interesting but we also would need to make sure we dont introduce new voulnerabilities.

[ghiscoding]

Like I wrote earlier, I don't know how to replace the deprecated lib with the newer lib, it is not that straightforward and also like I wrote in the README I'm just a regular developer and user of Lerna the same as you are and I don't know the codebase that much more than you. I created this fork to make it smaller and update what I could, it's however hard for me to update something I'm not familiar with, so If you know how to fix it then please create a Pull Request.

On the other hand, I'll also say this

• the package is deprecated but that doesn't mean it has security vulnerabilities (at the moment there's none)
• all packages that could be updated were updated (I spent well over 2 months to create this fork)
• I'll also mention the same reply that Lerna's author wrote as this comment

Again, if you know how to replace & fix this then please create a Pull Request

[fyyyyy]

Yes, i really appreciate your effort here. Unfortunately I dont have a solution either.

[carbontwelve]

I'm planning on pulling down this repo tonight to see if I can shed some light on this and towards a valid solution.

[ghiscoding]

fixed with PR #181 and now released under v1.4.0