Describe the bug

A high severity security vulnerability exists in the lodash.template dependency of this project (version 4.5.0). The suggested fix by npm audit is to downgrade the oclif package to v3. The lodash.template dependency does not have a patch, and should probably be replaced by either lodash or lodash-es in this project.

More info: GHSA-35jh-r3h4-6jhm

To Reproduce
Steps to reproduce the behavior:
Run npm audit in a project that uses this package.

Expected behavior
There are no security vulnerabilities.

Screenshots

Environment (please complete the following information):

        "@oclif/core": "^3.26.4",
        "@oclif/plugin-help": "^6.0.21",
        "@oclif/plugin-plugins": "^5.0.14",
        "oclif": "^4.8.8",

Additional context
Add any other context about the problem here.

Hi there! I've been working on a CLI tool with Oclif for my company and needed update warnings, however, wasn't able to directly use this package due to our CLI being hosted on a private npm registry; So I wrote a quick little alternative implementation, building off several other building blocks that already exist:

import { Hook } from "@oclif/config";
import libnpm, { Manifest } from "libnpm";
import semver from "semver";
import fs from "fs-extra";
import path from "path";
import cli from "cli-ux";

const timeoutInDays = 10;

const hook: Hook<"init"> = async function({ config }) {
  const { name: packageName, version: currentVersion } = config;
  const updateCheckPath = path.join(config.cacheDir, "last-update-check");

  const refreshNeeded = async () => {
    try {
      const { mtime } = await fs.stat(updateCheckPath);
      const staleAt = new Date(
        mtime.valueOf() + 1000 * 60 * 60 * 24 * timeoutInDays
      );
      return staleAt < new Date();
    } catch (err) {
      return true;
    }
  };

  const checkForUpdate = async () => {
    try {
      cli.action.start("checking for updates");

      const latestManifest: Manifest = await libnpm.manifest(
        `${packageName}@latest`,
        libnpm.config.read()
      );

      await fs.writeFile(updateCheckPath, JSON.stringify(latestManifest), {
        encoding: "utf8"
      });
    } finally {
      cli.action.stop();
    }

    await checkVersion(true);
  };

  const readLatestManifest = async (): Promise<Manifest | null> => {
    try {
      return JSON.parse(
        await fs.readFile(updateCheckPath, {
          encoding: "utf8"
        })
      );
    } catch (err) {
      return null;
    }
  };

  const checkVersion = async (printStatus?: boolean) => {
    const latestManifest = await readLatestManifest();

    // No version check has happened, so we can't tell if we're the latest version:
    if (latestManifest === null) {
      return null;
    }

    if (semver.lt(currentVersion, latestManifest.version)) {
      this.warn(
        `Update needed, please run \`yarn global add ${packageName}@latest\`\n`
      );
    } else if (printStatus) {
      this.log("All up-to-date!\n");
    }
  };

  if (await refreshNeeded()) {
    await checkForUpdate();
  } else {
    await checkVersion();
  }
};

export default hook;

I figure it might be of interest to the authors, as it uses libnpm for interacting with npm and follows semver semantics.

We have a CLI created with oclif which uses this plugin. The CLI is for an application shell framework we developed. The version check has been great for development-time prompts to help people get up-to-date with the CLI, but the version check is causing application crashes when it tries to writes out version information to a /.cache directory.

At runtime we don't want this version check to occur. Is there a way to disable the check dynamically so we can suppress the side effect?

This project has some moderate security vulnerabilities. Please update version of dependencies in this project which are impacted.

The devDependency @types/node was updated from 10.10.0 to 10.10.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

The push permission to the Git repository is required.

semantic-release cannot push the version tag to the branch master on remote Git repository.

Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.

Good luck with your project ✨

Your semantic-release bot 📦🚀

The dependency @oclif/config was updated from 1.7.4 to 1.7.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@oclif/config is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

The plugin does not show any messages in my application after switching to use scoped package. I used to get a message to update my application because there was an other package with the same name (pdftools) on npm!

{
	"name": "@bader-nasser/pdftools",
	"bin": {
		"pdftools": "bin/run.js",
		"pdf-tools": "bin/run.js"
	},
	"repository": "bader-nasser/pdftools",
        "dependencies": {
		"@oclif/core": "^2.15.0",
		"@oclif/plugin-autocomplete": "^2.3.8",
		"@oclif/plugin-help": "^5.2.19",
		"@oclif/plugin-not-found": "^2.4.1",
		"@oclif/plugin-plugins": "^3.4.2",
		"@oclif/plugin-warn-if-update-available": "^2.1.0",
	},
	"devDependencies": {
		"@oclif/test": "^2.5.3",
		"oclif": "^3.15.0",
	},
	"files": [
		"/bin",
		"/dist",
		"/npm-shrinkwrap.json",
		"/oclif.manifest.json",
		"/data.schema.json"
	],
	"oclif": {
		"bin": "pdftools",
		"binAliases": [
			"pdftools",
			"pdf-tools"
		],
                // not sure about this property, and couldn't find any docs if it affects the plugin
		"scope": "bader-nasser",
		"dirname": "pdftools",
		"commands": "./dist/commands",
		"additionalHelpFlags": [
			"-h"
		],
		"additionalVersionFlags": [
			"-v"
		],
		"plugins": [
			"@oclif/plugin-help",
			"@oclif/plugin-plugins",
			"@oclif/plugin-autocomplete",
			"@oclif/plugin-not-found",
			"@oclif/plugin-warn-if-update-available"
		],
		"warn-if-update-available": {
			"timeoutInDays": 7
		},
		"topicSeparator": " "
	}
}

OS: Ubuntu 23.04

My cli: https://github.com/bader-nasser/pdftools

I'm not sure if this is a bug or I'm missing something!

some brief testing seems to make it seem as this isn't working on windows

The file never seems to get created. I think it's either because the parent is closing before it has time to make the request, or something is failing inside the get_version script.

The README says

In package.json, set oclif['warn-if-update-available'].timeoutInDays to change the timeout duration between checks.

Where does this go exactly in the package.json?

Is there any support for checking for updates based on a project published via oclif-dev publish as opposed to npm? It seems like it shouldn't be necessary to publish to two places in order to get upgrade warnings working.

Describe the bug

As of 3.0.13, the dev dependencies of @oclif/plugin-warn-if-update-available end up in the end user's node_modules

To Reproduce

devel/experiments/tmp
❯ npm i @oclif/plugin-warn-if-update-available

added 1057 packages in 4s

14 packages are looking for funding
  run `npm fund` for details

devel/experiments/tmp via  v20.11.1 took 4s
❯ npm ls mocha
tmp@ /Users/Dominykas_Blyze/devel/experiments/tmp
└─┬ @oclif/[email protected]
  └── [email protected] extraneous


devel/experiments/tmp via  v20.11.1
❯ rm -rf node_modules

devel/experiments/tmp via  v20.11.1 took 4s
❯ npm i @oclif/[email protected]

added 107 packages, and audited 108 packages in 962ms

18 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

devel/experiments/tmp via  v20.11.1
❯ npm ls mocha
tmp@ /Users/Dominykas_Blyze/devel/experiments/tmp
└── (empty)

Expected behavior

Dev dependencies should not be installed

Screenshots

n/a

Environment (please complete the following information):

• OS & version: macOS, Node 20.x, npm 10.x
• Shell/terminal & version: should not matter

Additional context

FWIW, npm has never done a good job respecting the shrinkwraps included as part of dependencies - it does not work consistently or reliably (it can be ignored at times, pulling in latest dependencies, rather than what is pinned, etc).

Using a shrinkwrap also creates problems in deduplication, e.g. @oclif/plugin-plugins has [email protected], but latest is [email protected] and so you end up with two versions of oclif in your dependency tree.

Version 3.2.0 of debug was just published.

This version is covered by your current version range and after updating it in your project the build failed.

debug is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Dear @expo/plugin-warn-if-update-available maintainers,
Thank you for your contribution to the open-source community.

This issue was automatically created to inform you a new version (2.1.0) of @expo/plugin-warn-if-update-available was published without a matching tag in this repo.

Our service monitors the open-source ecosystem and informs popular packages' owners in case of potentially harmful activity.
If you find this behavior legitimate, kindly close and ignore this issue. Read more

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

The push permission to the Git repository is required.

semantic-release cannot push the version tag to the branch master on remote Git repository.

Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.

Good luck with your project ✨

Your semantic-release bot 📦🚀

While showing the update message: '<%= config.name %> update available from <%= chalk.greenBright(config.version) %> to <%= chalk.greenBright(latest) %>.', from where latest variable is coming? I checked in this file, but I didn' get how it is populating.

If a new version of the CLI is found, every subsequent command execution displays the warning message. I'd prefer an option to specify how often the warning message should be displayed.

I am trying to pass an npm token as env var because my CLI tool is private, I was wondering if it's possible to do that.
As I see from here authorization can only be passed as a string.

Hi,

It will be useful for private npm repo that the plug-in checks if a registry key in package.json exists and uses it in this case to check the last update.

For example in my project :
"publishConfig": {
"registry": "https:/xxxx:yyyy/repository/npm-private/"
}

Is there a way to use this plugin to check for the plugins installed in your CLI?

When working with prerelease tags, we've noticed that the the plugin will warn the first time when a prerelease version has been published, for example x.x.x to x.x.x-alpha.x.

However, after that when the version has been bumped to prerelease, due to https://github.com/oclif/plugin-warn-if-update-available/blob/master/src/hooks/init/check-update.ts#L27 , there seems to be an early return due to the existence of -and there appears to no longer be any warning shown for further updates whether a prerelease or not. https://github.com/oclif/plugin-warn-if-update-available/blob/master/src/hooks/init/check-update.ts#L31 seems to indicate the possibility of splitting on a - and comparing at least the first part.

We were wondering what the reasoning is for the early return or if this is a case of unfinished logic?

Thanks