feat: prune orphaned Node.js versions after install, fixes #7325#7326
Conversation
| fi | ||
|
|
||
| # prune orphaned Node.js versions | ||
| log-stderr.sh n prune || true |
There was a problem hiding this comment.
I wasn’t sure if including log-stderr.sh here was worth it given that this command isn’t really essential. Happy to remove it.
There was a problem hiding this comment.
It's fine to use log-stderr.sh here.
stasadev
left a comment
There was a problem hiding this comment.
Thank you!
I'm pushing a new Docker image now.
Important: test starting/stopping the project, then disable Internet and start the project again. It should work as before.
| fi | ||
|
|
||
| # prune orphaned Node.js versions | ||
| log-stderr.sh n prune || true |
There was a problem hiding this comment.
It's fine to use log-stderr.sh here.
|
A new Docker image is ready, build artifacts will appear shortly below. |
|
Download the artifacts for this pull request:
See Testing a PR.
|
|
Hmm, it’s not working properly - it removes all the versions. Node still “works” but when restarting without an internet connection it fails over to Node 22 (presumably whatever is installed with the image by default). I think this may be because the prune command needs to be moved after the symlinks are added here:
https://github.com/tj/n/blob/f52d2172f12cd76f0efe9524690723f52ab74f40/bin/n#L477-L494 I’ve pushed a commit that moves the command. If that works I can squash the commits + force push if you’d like, not sure if you’d prefer that done upfront or if you’ll squash + merge |
We always squash on merge, no need to do it here. Pushing a new image. |
|
The new Docker image is ready. Before testing run: |
|
Great, it’s working now. With a Node 18 project, only 
|
|
Great! I'll test it later today as well. (Ignore the "Container tests" failure: it's unrelated to this PR.) |
0480dbd to
02c6ff9
Compare
|
Rebased to fix tests. |
stasadev
left a comment
There was a problem hiding this comment.
Thank you!
There might be cases where someone wants to install multiple Node versions, but they can work around it by using a different N_PREFIX.
The logic behaves as expected:
$ ddev config --nodejs-version="14.1.0"
$ ddev start
$ ddev exec node -v
v14.1.0
$ ddev exec "n install 14 && n install 16 && n install 18"
$ ddev exec n ls
node/14.1.0
node/14.21.3
node/16.20.2
node/18.20.8
$ ddev config --nodejs-version="14"
$ ddev restart
$ ddev exec node -v
v14.21.3
# only one version as expected
$ ddev exec n ls
node/14.21.3
$ ddev exec "n install 14.21.2 && n install 14.21.1 && n install 14.21.0"
$ ddev exec n ls
node/14.21.0
node/14.21.1
node/14.21.2
node/14.21.3
$ ddev poweroff
# turn off the Internet
$ ddev start
$ ddev exec node -v
v14.21.3
# only one version as expected
$ ddev exec n ls
node/14.21.3
$ ddev restart
$ ddev exec node -v
v14.21.3
# only one version as expected
$ ddev exec n ls
node/14.21.3
The Issue
How This PR Solves The Issue
Runs the
n prunecommandManual Testing Instructions
Open the
ddev-global-cachevolume and look at a long-standing project’s directory:n_prefix/<project-name>/n/versions/node/. It’ll likely already contain multiple Node.js versions.After this change, the next time you start DDEV only the most recent Node.js version should be present
Automated Testing Overview
I’m not really sure how you’d test this, but given that this is a non-essential enhancement (everything’s running fine without this change, it just saves some disk space) I don’t think additional testing is necessary
Release/Deployment Notes
N/A