chore(deps): update dependencies within existing semver ranges

[arthurschreiber]

Summary

Refreshes package-lock.json to pull in the latest in-range versions of dependencies and devDependencies. The only package.json change is a new overrides block that keeps the transitive @azure/* packages on their Node-18-compatible line (see below); the engines.node requirement (>=18.17) is unchanged.

Notable bumps include @typescript-eslint/*, @stylistic/eslint-plugin, eslint, iconv-lite, mocha, sinon, typedoc, jws/jwa, and @types/node (range >=18).

Keeping @azure/* on the Node-18 line

The direct @azure/* dependencies are held at their current Node-18-compatible versions — the latest in-range releases (@azure/core-auth 1.10.x, @azure/identity 4.13.x, @azure/keyvault-keys 4.10.x) declare engines.node: >=20.0.0, which would raise the runtime Node floor. Bumping them is deferred to a change that also bumps the supported Node versions (see #1700 / #1735).

However, the lockfile refresh also pulled several transitive @azure/* packages up to releases that likewise require engines.node: >=20.0.0. On the Node 18 Azure CI jobs, @azure/core-rest-pipeline@1.24.0 fails MSAL's token request with network_error: Network request failed, which broke every Entra-based Azure integration job. To keep Node 18 support intact, an overrides block bounds these packages below their first >=20 release:

"overrides": {
  "@azure/core-client": "<1.10.0",
  "@azure/core-rest-pipeline": "<1.22.0",
  "@azure/core-tracing": "<1.3.0",
  "@azure/core-util": "<1.13.0",
  "@azure/logger": "<1.3.0"
}

Remove this block when the supported Node baseline is raised to 20.

Note: commits 5ffe1792 / b89edb8e add and then revert a fedauth AggregateError message tweak — added mid-investigation to surface the underlying MSAL error, reverted once the root cause was pinned. Net: no src/ change.

Superseded PRs

This refresh already brings the lockfile to (or past) the versions these dependency PRs target:

Fixes: #1711
Fixes: #1724

(Note: GitHub's Fixes keyword only auto-closes issues, not PRs, so these may need to be closed manually.)

Verification

• npm run build — clean
• npm run lint (eslint + tsc) — clean
• npm test — 394 passing
• Azure SQL integration jobs (SQL auth, AAD password, token-credential, service-principal) — green on Node 18 (previously failing with the MSAL network_error)

🤖 Generated with Claude Code

[arthurschreiber]

@claude can you review again?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.06%. Comparing base (5717f91) to head (b89edb8).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1741      +/-   ##
==========================================
+ Coverage   79.82%   80.06%   +0.24%     
==========================================
  Files          90       90              
  Lines        4901     4901              
  Branches      923      923              
==========================================
+ Hits         3912     3924      +12     
+ Misses        687      672      -15     
- Partials      302      305       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[claude]

Code Review: chore(deps): update dependencies within existing semver ranges

Overview

This is a lockfile-only refresh (package-lock.json) that bumps all in-range transitive dependencies without touching package.json. The net effect is a cleaner, more deduplicated dependency tree with updated patch/minor releases.

---

Positives

• Well-scoped: Only package-lock.json is changed — no semver range changes, no unintended scope creep.
• Clear rationale for held-back packages: The PR description explicitly documents why @azure/* packages are held at their current versions (their latest in-range releases now declare engines.node: >=20.0.0), and links the follow-up issue (chore: bump the supported node versions #1700 / chore: updating azure sdk to fix vulnerabilities #1735). This is exactly the kind of reasoning that should be in a lockfile PR.
• Verified before submission: Build, lint, and full test suite (390 passing, 4 pending) were run — no regressions.
• Tree deduplication: A significant number of nested duplicate packages (~180 removed entries) were eliminated. This is a maintenance win and reduces exposure to stale sub-versions.

---

Notable Version Changes

Package	Old	New	Notes
iconv-lite	0.7.0	0.7.2	Runtime dep — patch update, good to have
jws	4.0.0	4.0.1	JWT signing library — patch with security fixes
@azure/abort-controller	1.0.4 (nested)	2.1.2 (hoisted)	Was already nested under @azure/core-auth which requires ^2.0.0; now correctly hoisted
@aashutoshrathi/word-wrap	present	removed	Deprecated package eliminated
@babel/*	7.28.x	7.29.7	Uniform minor bump across the Babel toolchain
@typescript-eslint/*	8.x	8.x (latest)	Dev-only, no runtime impact

---

Observations & Minor Notes

1. @azure/abort-controller major bump (1 → 2): This looks alarming on first glance but is correct — @azure/core-auth@1.7.2 already required ^2.0.0, so v2 was always being installed as a nested copy. npm has now hoisted it to the top-level tree. No behavioral change.

2. jws 4.0.0 → 4.0.1: This is a JWT library used in the auth path. Patch bump is appropriate; worth noting that running npm audit could confirm no known advisories remain outstanding after the refresh.

3. @azure/* intentional hold: The chosen versions (@azure/core-auth 1.7.2, @azure/identity 4.2.x, @azure/keyvault-keys 4.4.x) are correct for staying on Node 18 compatibility. This is well-documented.

4. No resolved/integrity regressions: The diff shows resolved and integrity fields being added to previously bare entries (e.g. @azure/core-auth), which is an improvement in supply-chain auditability.

---

No Issues Found

• No source code changes — only the lockfile.
• No semver range changes.
• No new direct dependencies introduced.
• The Azure hold-back is intentional and documented.
• Test suite confirms no regressions.

---

Verdict

LGTM. This is a clean, well-reasoned dependency refresh. The documentation of the Azure hold-back is particularly appreciated — future maintainers will understand why those packages weren't bumped. Ready to merge.

[claude]

Code Review: chore(deps): update dependencies within existing semver ranges

Overview

This PR refreshes package-lock.json to pull in the latest in-range versions of dependencies, and also adds an overrides section to package.json to hold back certain Azure transitive packages that have raised their Node.js floor to >=20. The lockfile restructuring is large (~8k lines) but expected for this type of maintenance update.

---

Issues

1. PR description is inaccurate

No package.json changes

This is incorrect. The PR adds a new overrides section to package.json:

"overrides": {
  "@azure/core-client": "<1.10.0",
  "@azure/core-rest-pipeline": "<1.22.0",
  "@azure/core-tracing": "<1.3.0",
  "@azure/core-util": "<1.13.0",
  "@azure/logger": "<1.3.0"
}

This is actually the most significant and load-bearing part of the PR — it's what makes the Node 18 constraint hold. The description should be updated to call this out explicitly, and the rationale (Node 20 floor in newer Azure core packages) should be documented there.

2. Upper-bound overrides are fragile and invisible to consumers

The override constraints use strict upper bounds (<1.10.0, <1.22.0, etc.) rather than a fixed version pin (1.9.x). A few concerns:

• Silent resolution surprises: If @azure/identity or @azure/keyvault-keys later introduces a peer dependency that requires @azure/core-rest-pipeline >=1.22.0, npm will silently install a version that satisfies both — potentially violating the intent of the override. There's no error, just a runtime surprise.
• Maintenance burden: These bounds will need manual tracking. Nothing in the toolchain will alert maintainers when a bumped Azure package requires a version past one of these caps. A comment in package.json pointing to the tracking issue (chore: bump the supported node versions #1700 / chore: updating azure sdk to fix vulnerabilities #1735) would help future contributors understand why these overrides exist.
• overrides are npm-only: Yarn and pnpm users (or CI that uses them) won't get these constraints. Worth noting if the project ever widens its supported package managers.

3. New transitive packages added without mention

The following packages appear in the lockfile for the first time and warrant a brief note in the PR:

• @azure-rest/core-client (2.4.0) — new REST client foundation in the Azure SDK
• @typespec/ts-http-runtime — pulled in transitively by @azure-rest/core-client
• @azure/msal-browser and @azure/msal-node — new MSAL packages replacing the older jws-based authentication flow in @azure/identity

These are all from Microsoft's own Azure SDK and appear benign, but they meaningfully expand the dependency surface.

4. open package: major version jump (v8 → v10) in transitive deps

@azure/identity's transitive dependency on open jumped from v8 to v10. This is a significant skip (v9 dropped CJS support, v10 added further ESM-only changes). Since this is two levels deep and tests pass, it's likely fine — but worth a sanity check if @azure/identity is exercised in integration tests.

---

Positive observations

• Removing @aashutoshrathi/word-wrap (a temporary vulnerability workaround package) is a good cleanup.
• Removing @azure/core-asynciterator-polyfill (no longer needed on Node 18+) is correct.
• Removing duplicate per-package copies of @azure/abort-controller and @azure/core-tracing (previously duplicated under several node_modules/@azure/core-*/node_modules/) reduces install size.
• jws bumped from 4.0.0 → 4.0.1 and jwa from 2.0.0 → 2.0.1 picks up minor fixes, good.
• The stated verification (npm run build, npm run lint, npm test — 390 passing, 4 pending) is the right bar for a lockfile PR.

---

Suggestions

1. Update the PR description to accurately state that package.json gains an overrides section and explain why.
2. Add an inline comment (or a // See #1700 note in the overrides block if JSON permitted it) — since JSON doesn't allow comments, at minimum document this in the PR description and link to the tracking issue so the overrides don't look mysterious to the next person who runs npm install.
3. Consider pinning to exact max-safe versions (e.g., "@azure/core-rest-pipeline": "1.21.x") rather than open-ended upper bounds, so the intent is clearer and npm's deduplication is more predictable.

---

Risk Assessment

Low overall. No source code changes, all tests pass. The main risk is the overrides approach silently breaking if the Azure SDK evolves in unexpected ways — but that's a future concern and the PR is explicitly deferring Azure bumps to #1735.

[claude]

Code Review: chore(deps): update dependencies within existing semver ranges

Overview

This PR refreshes the lockfile, adds overrides to package.json to cap Azure sub-packages below their Node >=20 boundary, and fixes AggregateError messages in src/connection.ts. The stated goal is "no package.json changes" but in practice three files change, which is worth noting.

---

package.json — overrides block

Concern: PR description says "No package.json changes" but package.json was modified.

The overrides block is a necessary addition given the Azure package situation, but it slightly misrepresents the PR scope.

Concern: Upper-bound ranges are implicit pinning. These ranges will silently pick the highest available version below the ceiling. When Node 20 support lands (see #1700 / #1735) these overrides must be removed. Recommend opening a tracking issue or leaving a comment in the file pointing to the relevant PR, so this does not become forgotten tech debt.

Note: overrides only affect the repo itself, not downstream consumers. Since tedious is a published package, these constraints do not propagate to users who install tedious. This is correct npm behaviour but worth confirming was the intent.

---

package-lock.json — transitive major version bumps

The PR description calls out notable bumps but omits significant ones pulled in by @azure/identity 4.3.0 to 4.10.1:

Package	Before	After	Notes
@azure/identity	4.3.0	4.10.1	7 minor versions within ^4.2.1 range
@azure/msal-browser	3.17.0	4.30.0	Major version bump
@azure/msal-node	2.9.2	3.8.10	Major version bump
@azure/msal-common	14.12.0	15.17.0	Major version bump
jwa	1.4.1	2.0.1	Major version bump (JWT crypto lib)
@azure/core-rest-pipeline	1.16.1	1.21.0	5 minor versions; gains @typespec/ts-http-runtime dep
iconv-lite	0.7.0	0.7.2	patch
mocha	11.7.5	11.7.6	patch
sinon	21.0.0	21.1.2	minor

The MSAL major bumps (3 to 4 and 2 to 3) are the most significant risk. These are pulled in transitively by @azure/identity 4.10.x. The test suite passing (390 passing, 4 pending) is reassuring, but Azure AD/Entra authentication flows are notoriously hard to cover in unit tests — these changes should be verified in a real AAD environment (integration tests) before merging.

The jwa 1 to 2 major bump is notable since this is a JWT signing algorithm library in the authentication path. It appears to be caused by de-duplication of a previously nested copy (node_modules/jws/node_modules/jwa is removed; both packages now share root node_modules/jwa@2.0.1). The change looks structurally correct but should be explicitly verified.

New package introduced: @azure-rest/core-client@2.4.0 appears in the lockfile as a new transitive dependency — worth acknowledging as incremental supply-chain surface area.

---

src/connection.ts — AggregateError improvements

The PR adds a second message argument to two AggregateError throws in the fedauth token path:

• When credentials.getToken() rejects: message includes the underlying error's message via err instanceof Error ? err.message : String(err)
• When the token response is null: message is the static string 'Security token could not be authenticated or authorized.'

This is a good change. Without a message, AggregateError surfaces as [object AggregateError] in some contexts, making debugging painful. The instanceof Error guard is correct defensive TypeScript.

Minor concern: This change is unrelated to dependency updates. It would be cleaner in its own PR for history clarity, but it is non-breaking and a clear improvement.

Missing tests: No unit tests verify the new AggregateError message format. Existing fedauth error path tests should be updated to cover the new message.

---

Summary

Area	Status
Lockfile refresh strategy	Sound
Azure Node-18 holdback via overrides	Correct approach
MSAL major version jumps (3 to 4 and 2 to 3)	Needs integration test verification
jwa 1 to 2 major bump	Should be explicitly verified
connection.ts AggregateError messages	Good improvement
PR description accuracy	Slightly understates scope — package.json changed, MSAL major bumps not mentioned
Test coverage for new error messages	Missing

The approach is well-considered and the rationale for holding back the Node-20-only Azure packages is clearly explained. The main asks are: (1) verify MSAL major version jumps work correctly in real auth scenarios via integration tests, and (2) ensure the overrides removal is tracked alongside the Node 20 upgrade work in #1700 / #1735.

[github-actions]

🎉 This PR is included in version 19.2.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀