deps: stop re-raising two impossible majors; move node to 24 LTS - #92
Merged
Merged
Conversation
Dependabot re-opened the same two dead NuGet majors every week, and both were just closed again with the build output attached: - SixLabors.ImageSharp 4.x fails the build demanding a paid license key. - Microsoft.OpenApi 3.x makes IOpenApiMediaType.Example read-only, which the Microsoft.AspNetCore.OpenApi source generator still assigns to (CS0200) -- the same reason 2.7.5 was pinned in 85ea04b. Only an ASP.NET Core release built against OpenApi 3.x can unblock it. Both are now ignored at semver-major so they stop generating weekly noise. Separately, the node 22 -> 25 bump was closed: 25 is non-LTS and outside the engines range in frontend/package.json. This moves to 24 (LTS, inside that range) and does it in all four places at once -- Dockerfile, ci.yml, the devcontainer feature, and the README -- since the previous state had the image on 22, CI on 22 and the devcontainer on 22 with nothing keeping them in step.
This was referenced Aug 31, 2026
thomas-lg
added a commit
that referenced
this pull request
Aug 31, 2026
…nt (#104) Dependabot's first run under the new grouping offered node 24-slim -> 26-slim. CI passed -- npm's engines check is only a warning, and only the Dockerfile moved -- but taking it would ship an image built on node 26 while ci.yml and the devcontainer still test on 24, re-introducing exactly the drift #92 removed. It is also outside the engines range the project declares, and node 26 is still Current rather than LTS. node's major is therefore pinned, matching the typescript rule: it moves deliberately with an Angular upgrade, across all four references at once. Digest and minor updates keep flowing. The Dockerfile comment claimed odd-numbered majors were what gets skipped; 26 is even, so that was wrong. The real gate is the engines range plus LTS status.
thomas-lg
added a commit
that referenced
this pull request
Sep 13, 2026
Dependabot re-opened the same two dead NuGet majors every week, and both were just closed again with the build output attached: - SixLabors.ImageSharp 4.x fails the build demanding a paid license key. - Microsoft.OpenApi 3.x makes IOpenApiMediaType.Example read-only, which the Microsoft.AspNetCore.OpenApi source generator still assigns to (CS0200) -- the same reason 2.7.5 was pinned in 69f82dc. Only an ASP.NET Core release built against OpenApi 3.x can unblock it. Both are now ignored at semver-major so they stop generating weekly noise. Separately, the node 22 -> 25 bump was closed: 25 is non-LTS and outside the engines range in frontend/package.json. This moves to 24 (LTS, inside that range) and does it in all four places at once -- Dockerfile, ci.yml, the devcontainer feature, and the README -- since the previous state had the image on 22, CI on 22 and the devcontainer on 22 with nothing keeping them in step.
thomas-lg
added a commit
that referenced
this pull request
Sep 13, 2026
…nt (#104) Dependabot's first run under the new grouping offered node 24-slim -> 26-slim. CI passed -- npm's engines check is only a warning, and only the Dockerfile moved -- but taking it would ship an image built on node 26 while ci.yml and the devcontainer still test on 24, re-introducing exactly the drift #92 removed. It is also outside the engines range the project declares, and node 26 is still Current rather than LTS. node's major is therefore pinned, matching the typescript rule: it moves deliberately with an Angular upgrade, across all four references at once. Digest and minor updates keep flowing. The Dockerfile comment claimed odd-numbered majors were what gets skipped; 26 is even, so that was wrong. The real gate is the engines range plus LTS status.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to clearing the Dependabot backlog. Two unrelated bits of hygiene that both came out of it.
1. Ignore two majors that can never be taken
Both were re-opened weekly, and both were closed again today with the build output on the PR:
No Six Labors license found. Set $(SixLaborsLicenseKey) .... 4.x is commercially licensed.IOpenApiMediaType.Exampleread-only, and theMicrosoft.AspNetCore.OpenApisource generator still assigns to it (CS0200). Nothing we can do from here; it needs an ASP.NET Core release built against OpenApi 3.x. This is the same constraint behind the 2.7.5 pin in 85ea04b — and deps: Bump Microsoft.AspNetCore.Authentication.JwtBearer and 12 others #82 has since moved us to 2.12.2, so the NU1903 audit concern is handled without leaving 2.x.Both are now ignored at
semver-majoronly, with the reason and the actual error in a comment so the next person doesn't re-litigate it. Minor/patch updates still flow.2. Node 22 → 24 (LTS), in all four places at once
#77 proposed node 25, which is non-LTS and outside the range
frontend/package.jsondeclares:Closed in favour of 24, which is the current LTS and inside that range.
The more useful part is that this moves all four references together — the Dockerfile, both
node-versionentries inci.yml, the devcontainer's node feature, and the README. Before this, the image, CI, and the devcontainer were each independently pinned to 22 with nothing keeping them in step, which is how #77 would have silently left the production image on a different major from CI.Verification
The
docker-buildjob builds the Dockerfile and thefrontendjob runs the production build plus all seven vitest projects — both now on node 24, so the required checks are the verification. Worth a "Rebuild Container" locally to confirm the devcontainer picks up 24.