Dependencies cleanup targeting the next major version bump

[rpl]

This package has not been actively maintained for quite some time, and so there are some dependencies that may not really be necessary anymore (e.g. because in the meantime they got replaced with the official JS feature being more widely supported) and some other ones did got background incompatible changes in new major version released in the meantime.

This issue is meant to track cleanup work related to these dependencies:

• when (pull requests fix(deps): update dependency when to v3.7.8 #60)

  • determine what is it used for: apparently only used to polyfill a Promise and to promisify which (which in more recent versions seems to be already be returning a promise when no callback is passed to it):
  • next action: remove dependency in a major version, along with bumping the minimum supported nodejs version**

• which (pull requests fix(deps): update dependency which to v1.3.1 #61, fix(deps): update dependency which to v2 - autoclosed #67

  • determine what is it used for: used only linux, to resolve the full path to an executable based on the executable name
  • next action: close fix(deps): update dependency which to v1.3.1 #61 in favor of fix(deps): update dependency which to v2 - autoclosed #67 (and include in a new major version along with when change described above)

• commander (pull requests fix(deps): update dependency commander to v2.20.3 #58, fix(deps): update dependency commander to v8 - autoclosed #83

  • determine what is it used for: this is only used for the bin/ script and not for the library itself
  • next action:
    • look into the CI job failure from fix(deps): update dependency commander to v8 - autoclosed #83 (determine if the small bin script or the test, or both, needs to be udjusted)
    • close fix(deps): update dependency commander to v2.20.3 #58 minor version bump, in favor for fix(deps): update dependency commander to v8 - autoclosed #83 major version bump** (also better included in a major version bump)

• winreg (pull requests fix(deps): update dependency winreg to v0.0.18 #62, fix(deps): update dependency winreg to v1 #68):

  • determine what is it used for: (this is very likely we used to determine the path to installed Firefox versions' executable on windows)
  • next action: close fix(deps): update dependency winreg to v0.0.18 #62 in favor of fix(deps): update dependency winreg to v1 #68 (also better included in a major version bump)

• spawnsync (pull requests fix(deps): update dependency spawn-sync to v2 #66):

  • determine what is it used for: (can we get rid of it or is it still useful on more modern nodejs versions?)
  • next action: either merge or drop the dependency

[fregante]

I can work on this cleanup if someone is available to review the resulting PR(s)

[fregante]

winreg is needed on windows, it's light (no deps), it's supported (oct 2023), it doesn't look like there have been breaking changes, and the open dependabot PR is green:

• chore(deps): bump winreg from 0.0.12 to 1.2.5 #125

It just needs a click to be merged.

The last one now is which, which is blocked by when due to some overlapping code:

• Drop when dependency #136

[Araxeus]

winreg is needed on windows, it's light (no deps), it's supported (oct 2023), it doesn't look like there have been breaking changes, and the open dependabot PR is green

Winreg is not actively maintained - could use https://github.com/desktop/registry-js instead

[fregante]

Winreg is not actively maintained

The last release was just 10 months ago. Unless you had issues with this package, I reckon it's good enough for the purposes of fx-runner

could use desktop/registry-js instead

I'd advise against that, check out the deps tree: https://npmgraph.js.org/?q=registry-js

Versus zero dependencies: https://npmgraph.js.org/?q=winreg

[Araxeus]

Unless you had issues with this package

I did actually, and other users have reported issues on v1.2.5 (check around the last ~4 issues on https://github.com/fresc81/node-winreg )

If you end up choosing Winreg I recommend staying on v1.2.4 or at least check that those issues don't affect this project

I'd advise against that, check out the deps tree:

You may be right, but at least it's maintained by GitHub 🤷‍♂️

[fregante]

@rpl all other dependencies have been addressed by the way.

[Rob--W]

Unless you had issues with this package

I did actually, and other users have reported issues on v1.2.5 (check around the last ~4 issues on https://github.com/fresc81/node-winreg )

Can you be more specific on how these issues affect the package here? We do not create registry keys, we use the module in read-only mode. Is there a test case that breaks our use case?

[Araxeus]

My issues occur when trying to create a new key indeed, that's why I said
"atleast check that those issues don't affect this project"

I'm just seeing a package that released a new broken version almost a year ago and didnt bother to fix it