Repository navigation
chore(deps): update all NuGet and npm packages to their latest stable versions - #495
Merged
Merged
Conversation
Refreshed every central pin against nuget.org; `dotnet list package --outdated` is now empty for the whole CI solution filter. New in this commit: AngleSharp 1.10.0->1.10.1, AWSSDK.Core 4.0.102.18->4.0.102.19, HtmlSanitizer 11.0.16->11.0.26, xunit.v3 4.0.2->4.0.3 (all four test projects), YesSql.Core and YesSql.Provider.Sqlite 6.1.0->6.2.0. Carried over from the unpushed working tree, which had already swept: Grpc.* 2.84.0->2.85.0, HtmlSanitizer 9.2.1039->11.0.16, KubernetesClient 19.0.2->21.0.8, the Microsoft.* 10.0.13->10.0.14 wave (EF Core, Data.Sqlite, Mvc.Testing, Extensions.Hosting), Microsoft.Identity.Client(.Extensions.Msal) 4.91.1->4.92.0, Microsoft.VisualStudio.DiagnosticsHub.BenchmarkDotNetDiagnosers 18.12->18.13, Markdig 1.5.0->1.6.0, System.Security.Cryptography.Pkcs 9.0.21->10.0.14, Microsoft.SourceLink.GitHub 10.0.402->10.0.403, YesSql 6.0.0->6.1.0. Two transitive security pins close the advisories that session 85 of docs/performance/WORKLOG.md had to log BLOCKED on the "never modify package versions" rail: SixLabors.ImageSharp 3.2.0 (OrchardCore 3.0.1 resolved the vulnerable 3.1.11, GHSA-gwg2-r3hj-4w44, fixed in 3.2.0 within the same major line) and MySqlConnector 2.6.2 (OrchardCore resolved 2.4.0, NU1902/NU1903). `dotnet list SharpCoreDB.sln package --vulnerable --include-transitive` now reports SharpCoreDb.Orchardcore clean. Directory.Build.props follows Microsoft.Data.Sqlite to 10.0.14, so its PackageVersion Update stays level with the central pin instead of silently pinning a downgrade. Dropped linq2db.Provider.SQLite 6.0.0: no project references it and the id does not exist on nuget.org or either configured MyGet feed (search and flat container both return nothing), so it was inert and an NU1101 trap for the next reference. src/SharpCoreDB.Functional.Linq2DB resolves its SQLite provider from linq2db 6.5.1 + Microsoft.Data.Sqlite, which is unchanged. SixLabors.ImageSharp is deliberately NOT bumped to 4.1.3: the pin exists to keep OrchardCore 3.0.1 on a patched 3.x, and a major bump is an API break for a package we only pin for the advisory. Verified: restore and Release build of SharpCoreDB.CI.slnf (0 errors); the four CI suites under Category!=Debug&Category!=Manual&Category!=Performance (2118 + 255 + 116 + 24 tests, 0 failures); --deprecated and --vulnerable clean on both the CI filter and the full SharpCoreDB.sln; Release builds of SharpCoreDB.AppHost, SharpCoreDB.Aspire.Hosting and the OrchardCore example.
CompiledQuery_VsRegularQuery_ReturnsSameResults built its VALUES literals with the current culture, so the SQL text it generated depended on the test machine's decimal separator. Formatting the value explicitly keeps the statement identical everywhere and makes the test independent of the host locale. Verified: 15/15 CompiledQuery tests pass on the updated package set.
`npm run typecheck` (tsc --noEmit) failed on master with eight errors, so the
client's own quality gate could not run at all:
grpc-client.ts(128,7) TS2412 assigning undefined to `_client?: DatabaseServiceClient`
grpc-client.ts(130,5) TS2412 assigning undefined to `_sessionId?: string`
grpc-client.ts(141,11) TS2375 `QueryParameters | undefined` into `parameters?`
http-client.ts(96,5) TS2412 assigning undefined to `_authToken?: string`
http-client.ts(97,5) TS2412 assigning undefined to `_database?: string`
ws-client.ts(100,7) TS2412 assigning undefined to `_ws?: WebSocket`
ws-client.ts(102,5) TS2412 assigning undefined to `_sessionId?: string`
ws-client.ts(103,5) TS2412 assigning undefined to `_database?: string`
Cause, not symptom: under `exactOptionalPropertyTypes: true` the optional form
`field?: T` forbids an explicit `undefined` assignment, and disconnect() releases
the socket/session exactly that way. The cleared fields are now declared
`field: T | undefined` (also exempt from strictPropertyInitialization, and still
falsy for the existing `if (!this._client || !this._sessionId)` guards), and the
two request builders use `...(parameters && { parameters })` instead of an
explicit `parameters: undefined` -- the same spread ws-client already uses for
its message payloads.
The tsconfig is not relaxed: exactOptionalPropertyTypes stays on, so the stricter
checks are preserved rather than muted.
Verified: tsc --noEmit 0 errors, tsup build OK, jest 16/16 pass -- run both
against the committed lockfile and against the refreshed one.
…nges
`npm update` in src/SharpCoreDBServerScriptClients/javascript/sharpcoredb-client.
package.json ranges are unchanged, so no release is implied; the direct bumps are
axios 1.20.0->1.21.1, @grpc/grpc-js 1.14.6->1.14.7, ws 8.22.0->8.22.2 and
@typescript-eslint/{eslint-plugin,parser} 8.72.0->8.72.2. No major-version moves.
Security effect: `npm audit` drops from 14 advisories (1 high, 6 moderate, 7 low)
to 13 (0 high, 6 moderate, 7 low), and `npm audit --omit=dev` reports 0 -- every
remaining advisory is in devDependencies (the jest 29 / eslint 8 lineage), for
which npm's own suggested "fix" is a downgrade to jest 25.1.0.
Deliberately NOT taken, because each needs a migration rather than a bump:
eslint 8->10 (flat config), jest 29->30, @types/jest 30, @types/node 20->26,
google-protobuf 3->4, tsup 8->9, typescript 5.9->7.
npm also re-normalised the platform-specific optional entries while regenerating:
one orphan @napi-rs/lzma-linux-x64-gnu entry went, @rollup/rollup-android-x64
was added for rollup 4.68.2. @rollup/rollup-linux-x64-gnu and
@rollup/rollup-win32-x64-msvc are both still present, so cross-platform
`npm ci` is unaffected.
Verified: npm ci clean, tsc --noEmit 0 errors, tsup build OK, jest 16/16 pass.
Owner
Author
Note on the "42 vulnerabilities" push bannerThe banner counts open Dependabot alerts on the default branch, not this PR's diff. Breakdown of the 42:
So: |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
BlockCompressor_Zstd_Compress_AllocatesOnlyTheReturnedFrame failed once on CI's rc.1 coverage runner with Compressing a 258,000-byte block allocated 4,376 bytes; at most 4.096 was expected (the returned frame). and then passed on a re-run of the same commit with no product change in between (job 129419150085: failure, then success), while master's own coverage run of the same suite passes today. So the product did not regress: a probe inside the test assembly measures the steady state at 176 B per call for a 151 B frame, i.e. 23x under the 4.096 B ceiling. The test measured exactly one call after the warm-up, so a one-off allocation landing inside that window - JIT tier-up, host instrumentation, a rebuild of the thread-static encoder - reads as a per-block cost. It now takes the cheapest of three measured calls, which is what the lever claims: a *reused* encoder over a *pooled* destination costs only the returned frame. Nothing is relaxed. The 4.096 B ceiling is unchanged, as is the frame-shape assertion, and the shape the lever replaced (129.496 B on every call for this payload, per the 2026-10-09 probe) still fails it by 30x. A proportional "allocation must not grow with the block" bound was tried first and rejected: a hand-built ZstandardStream shape allocates only ~750 B here, so that bound would not have caught the regression this test exists for. Verified: CompressionLevelTests 48/48; the four CI suites 2.118 + 255 + 116 + 24 with 0 failures; tools/measure-coverage.ps1 exit 0, 46.20% measured against the 18% floor.
|
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
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.
What this does
Brings every package pin in the repository up to its latest stable release, and fixes two defects found while verifying.
1. NuGet —
chore(deps): update all direct NuGet packages to their latest versionsAngleSharp1.10.0→1.10.1,AWSSDK.Core4.0.102.18→4.0.102.19,HtmlSanitizer11.0.16→11.0.26,xunit.v34.0.2→4.0.3,YesSql.Core/YesSql.Provider.Sqlite6.1.0→6.2.0.Grpc.*2.84→2.85,KubernetesClient19.0.2→21.0.8,HtmlSanitizer9→11, theMicrosoft.*10.0.13→10.0.14 wave,Microsoft.Identity.Client4.91.1→4.92.0,Markdig1.5.0→1.6.0,System.Security.Cryptography.Pkcs9.0.21→10.0.14,SourceLink10.0.402→10.0.403,YesSql6.0→6.1, and the BenchmarkDotNet diagnosers.BLOCKEDin session 85 ofdocs/performance/WORKLOG.md:SixLabors.ImageSharp3.2.0 (OrchardCore 3.0.1 resolved the vulnerable 3.1.11,GHSA-gwg2-r3hj-4w44) andMySqlConnector2.6.2 (OrchardCore resolved 2.4.0, NU1902/NU1903).dotnet list SharpCoreDB.sln package --vulnerable --include-transitivenow reportsSharpCoreDb.Orchardcoreclean.linq2db.Provider.SQLite6.0.0 — no project references it and the id exists on no configured feed (inert today, anNU1101trap for the next reference).SixLabors.ImageSharpis deliberately not taken to 4.1.3: the pin exists to keep OrchardCore 3.x on a patched 3.x, and a major bump is an API break for a package we only pin for the advisory.2. JS client —
fix(client-js): make the project type check pass againnpm run typecheckwas failing onmasterwith eightexactOptionalPropertyTypeserrors, so the client's own gate could not run. Fields cleared bydisconnect()are now declaredfield: T | undefinedinstead of the optional-property form, and the request builders use...(parameters && { parameters }).exactOptionalPropertyTypesis not relaxed — the stricter checks stay on.3. JS client —
chore(deps): refresh the JS client lockfile within existing semver rangesnpm updateonly;package.jsonranges unchanged.npm audit14 → 13 advisories, 0 high, andnpm audit --omit=devreports 0 — everything left is devDependencies.4. Test hygiene —
fix(tests): format the generated INSERT literal with InvariantCultureUncommitted working-tree fix carried in: the generated
VALUESliteral no longer depends on the host locale's decimal separator.Verification
dotnet restore+ Release buildSharpCoreDB.CI.slnfSharpCoreDB.Tests(CI filter)SharpCoreDB.VectorSearch.TestsSharpCoreDB.EntityFrameworkCore.TestsSharpCoreDB.Functional.Linq2DB.TestsCompiledQuerytests--deprecated/--vulnerableonSharpCoreDB.CI.slnf--vulnerable --include-transitiveonSharpCoreDB.slndotnet list package --outdatedon the CI filterSharpCoreDB.AppHost,SharpCoreDB.Aspire.Hosting, OrchardCore examplenpm ci,tsc --noEmit,tsup build,jestDeliberately not done
SixLabors.ImageSharp4.x, JSeslint10,jest30,typescript7,google-protobuf4,tsup9 — each is a migration, not a version bump.SharpCoreDBVersion/ package-version /global.jsonchange; nothing was packed or published.42 vulnerabilities (41 high, 1 low)in the push banner are Dependabot's count across the default branch; every NuGet project in this repo scope is clean and the only npm manifest now has 0 production advisories.