This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update dependency @octokit/core to v4.2.4
• chore(deps): update dependency chai to v4.5.0
• chore(deps): update dependency mocha to v10.7.0
• chore(deps): update dependency sinon to v15.2.0
• fix(deps): update dependency node-fetch to v2.7.0
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update dependency chai to v5
• chore(deps): update dependency sinon to v18
• fix(deps): update dependency @octokit/core to v6
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• fix(deps): update dependency node-fetch to v3

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

I've just stumbled upon #3 and #1 and I thought: why not simply execute a user provided script if an update is available? Then the user can decide if they want to send a mail, try an automated update or do something completely different.

Each software entry could take an optional script path to be executed. The script should accept the new version nr. and release download URL as arguments. Would be easier to implement than #1 and #3 and also more flexible imho...

Motivation: If software is installed from elsewhere than GitHub, it would be an idea to check the RSS feed of that software, if available.

Thoughts on the code:
One probably would have to add an RSS parser and run it in parallel to octogit.
See:

• https://www.npmjs.com/package/rss-parser
• rss-utils

Motivation: Make it the user's choice whether to use gotify for software update notifications, or receive them via email.

Thoughs on the code:
Should be some sort of interface* (e.g. notification-utils.mjs) that can be called with the same parameters. Based on configuration, either the gotify-utils or email-utils should be used to send out the notification.

*I'm a Java guy, thus I'm talking about interfaces. Not sure how one would properly realize such a pattern in JavaScript/Node.js

merging renovate pull-requests (and also other code changes) can be done with more confidence, if the existing code has a sufficient test coverage

Todo: get into the topic of node.js unit testing

affected versions of uuNotify: v1.1.3 (and higher)

Issue description:

Installation using the setup.sh script fails during npm clean-install step with following error:

Running 'npm clean-install' ...
npm WARN prepare removing existing node_modules/ before installation
npm ERR! Error while executing:
npm ERR! /usr/bin/git ls-remote -h -t ssh://[email protected]/mapbox/node-sqlite3.git
npm ERR! 
npm ERR! Permission denied (publickey).
npm ERR! fatal: Could not read from remote repository.
npm ERR! 
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.
npm ERR! 
npm ERR! exited with error code: 128
...

Root cause

A mix of npm v6 git dependency url resolution (ssh instead of https) and a workaround to get over a too old version of node-gyp in sqlite3 version 5.0.2. Won't go into details here.

The update of node-gyp in sqlite3 was already committed, but not yet packed into a new release of sqlite3. So there was the need to install sqlite3 from the git project directly, causing the issue described above.

Long term solution

update sqlite3 dependency, as soon as there is a new release of it on the npm registry, including the mentioned commit.

Workaround

Run 2 commands, one before, and one after ./setup.sh:

git config --global url."https://[email protected]".insteadOf ssh://[email protected]
./setup.sh
git config --global --remove-section url."https://[email protected]"

As you can see, this workaround requires changing a global git config. To avoid unwanted side-effects, you want to change this back with the second command, directly after setup.sh has completed!

Create release artifacts. A zip file containing only the relevant project files (in minified versions?), that can be downloaded (e.g. via wget).

The release artifacts should not include any files like

• contributing.md
• package.json (only package-lock.json)
• mocks/
• .gitignore

LICENSE.txt should be included!

Just a thought, not sure if it's a good or bad idea.

Try to auto-update patch levels (or even minor versions?). Send notification about update availability, execute update, send notification about success/failure.

Pros:

• less manual interaction if updates are available
• registering hooks to call update-scripts, located next to the installed software

Cons:

• Cannot rely on SemVer. Software could also introduce breaking changes in patch-levels.
• Other software doesn't follow Semver.
• Danger of breaking something is high.