Update update-notifier to v6

[MrArnoldPalmer]

• I have searched for similar issues
• I am using the latest version of npm-check-updates
• I am using node >= 14

update-notifier recently released v6 which upgrades it's dependency on got (deep down the tree) which currently has a CVE related.

v6 of update-notifier also migrates to pure ESM which would require consumers to also migrate. So upgrading requires NCU to use ESM and drop support for node 12 (which was already done), but also programmatic NCU consumers would have to migrate to ESM.

Not sure how interested you are in migrating NCU to pure ESM and/or if this CVE is a forcing function for that (NCU may not even be vulnerable I haven't found details to support one way or another) but I started making a PR to do the version upgrade but with the ESM changes it started growing quite large so I figured I should check first before dumping it here 😆

main...MrArnoldPalmer:chore/upgrade-notifier current state though build:options currently failing and I haven't dug in.

[raineorshine]

Thanks for the information and initial investigation.

I've followed the dependencies down and npm-check-updates does not appear to be vulnerable.

$ npm ls got
npm-check-updates@14.1.0 /Users/raine/projects/npm-check-updates
└─┬ update-notifier@5.1.0
  └─┬ latest-version@5.1.0
    └─┬ package-json@6.5.0
      └── got@9.6.0

• update-notifier only uses got via latest-version which uses package-json.
• package-json defaults to https://registry.npmjs.org/ via registry-url.
• update-notifier does not provide a custom registry option to latest-version.
• Thus, the registry will always be https://registry.npmjs.org/ and no UNIX redirect is possible.

programmatic NCU consumers would have to migrate to ESM.

I am more hesitant about this part. I was just working on a project where we wanted to create a submodule with its own tsconfig that referenced typescript modules in the parent project. After several hours of trying different combinations of tsconfig properties and import/export syntaxes, I eventually had to give up. The error messages are inscrutable and even when you diligently remedy one error it seems to be the exact cause of another.

Sindre had to write a whole FAQ to facilitate this transition in his modules. This is why I no longer upgrade them.

The best move may be no move at all until pure ESM becomes easier for the average user.

[MrArnoldPalmer]

I am more hesitant about this part.

Definitely makes sense. 👍🏻 Feel free to close this out or keep open for tracking as needed.

TY for the writeup re vulnerability of got that is very useful.

[JustusFluegel]

Small note from my side on this: As update-notifier is only used in the cli, which does not export anything, we could stay on cjs but still use update-notifier v6 by using dynamic imports like this:

// imports ...

async function cli() {
  const {default: updateNotifier} = await import("update-notifier");
  const notifier = updateNotifier({ pkg })
  if (notifier.update && notifier.update.latest !== pkg.version) {
    notifier.notify({ defer: false, isGlobal: true })
  }
  
  // the remaining code in cli.ts
}

void cli();

This would solve both problems as we can still use cjs for npm-check-updates but still use the ejs version of the package.
A minor caveat is that this would still require the engine version bump from >=14 to >=14.14 as ejs packages are only supported since this version.

[JustusFluegel]

I would be open to create a new issue / pr if that is welcome.

[raineorshine]

That sounds like a great compromise. The bump to node>=14.4 is fine.

[JustusFluegel]

gimme a sec, i'll fork & pr