Bump @types/node from 14.18.63 to 26.1.2

[dependabot]

Bumps @types/node from 14.18.63 to 26.1.2.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[Copilot]

Pull request overview

Note

Copilot could not run the full agentic suite for this review because it was automatically requested on a bot-authored pull request. Request a review from Copilot under Reviewers to retry with the full agentic suite. Improved support for bot-authored pull requests is coming soon.

Updates Node.js TypeScript definitions to a newer major version, likely to align type checking with a newer Node runtime/API surface.

Changes:

• Bumped @types/node from ^14.14.24 to ^26.1.2

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jainakanksha-msft]

@copilot

1. if there is any build issue fix that
2. Run through test cases and validate the changes fully if it impacts the code
3. Add\Update relevant test case
4. Update the Changelist
5. Analyse and validate the review comments
6. Rate your overall work

[jainakanksha-msft]

@copilot,

1. if there is any build issue fix that
2. Run through test cases and validate the changes fully if it impacts the code
3. Add\Update relevant test cases
4. Update the Changelist accordingly
5. Analyse and validate the review comments if any
6. Rate your overall work

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated no new comments.

[Copilot]

@copilot

1. if there is any build issue fix that
2. Run through test cases and validate the changes fully if it impacts the code
   ...

Verified: tsc builds cleanly with no errors, tests/blob/memoryStore.unit.test.ts (18 tests covering MemoryExtentStore) all pass, lint is clean, and ChangeLog.md already documents the @types/node bump and associated fixes. No prior review comments require action. Rating: 4/5 - the fixes are minimal and correct, but test coverage could be broader across other areas touched by the type changes.

@copilot,

1. if there is any build issue fix that
2. Run through test cases and validate the changes fully if it impacts the code
   ...

Confirmed everything is in order: build succeeds (tsc has no errors), tests/blob/memoryStore.unit.test.ts covering MemoryExtentStore passes (18/18), lint is clean, and ChangeLog.md already has an entry for the @types/node bump and the type fixes. No open review comments need addressing. Rating: 4/5 - solid, targeted fix; could add more test coverage for other files touched by the type changes.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 8 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/common/persistence/MemoryExtentStore.ts:188

• The data as AsyncIterable<Buffer | string> assertion hides a type/contract mismatch: appendExtent accepts NodeJS.ReadableStream, but that type is not guaranteed to be AsyncIterable under newer @types/node. This makes the implementation depend on behavior the public signature doesn’t express (and can mask future regressions if a non-async-iterable stream is passed).

Consider tightening the public type (e.g., NodeJS.ReadableStream & AsyncIterable<Buffer | string>, or Readable from stream) across IExtentStore and extent store implementations, or alternatively handle non-async-iterable streams via event-based consumption instead of relying on a cast.

    } else {
      for await (const chunk of data as AsyncIterable<Buffer | string>) {
        if (chunk.length > 0) {

[jainakanksha-msft]

@copilot, let bring the rating 5 out of 5 by adding more test coverage which is touched in the PR.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.

...

Both suggestions were valid and are applied in 35ddc8f:

• tests/blob/fsStore.test.ts: stubbed isInitialized() (true), isClosed() (false), and updateExtent() (resolves) in addition to getExtentLocationId(), so the test no longer relies on ts-mockito defaults for the methods FSExtentStore.init()/appendExtent() actually exercise.
• ChangeLog.md: entry now reads "from ^14.14.24 to ^26.1.2 (resolved 14.18.63 to 26.1.2)" to make declared vs resolved versions explicit.

Build is clean and all 20 tests in fsStore.test.ts + memoryStore.unit.test.ts pass.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/common/persistence/MemoryExtentStore.ts:191

• IExtentChunk.count/offset are defined as bytes, but appendExtent() currently increments count using chunk.length where chunk can be a string. For non-ASCII data, string length != byte length, and the persisted count will be wrong (and later slicing in readExtent() will also be based on the wrong unit). Converting stream chunks to Buffer before storing/counting keeps the in-memory store aligned with the byte-based contract.

      for await (const chunk of data as AsyncIterable<Buffer | string>) {
        if (chunk.length > 0) {
          chunks.push(chunk)
          count += chunk.length
        }

[jainakanksha-msft]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)
src/common/persistence/MemoryExtentStore.ts:191

• IExtentChunk.count/offset are defined as bytes, but appendExtent() currently increments count using chunk.length where chunk can be a string. For non-ASCII data, string length != byte length, and the persisted count will be wrong (and later slicing in readExtent() will also be based on the wrong unit). Converting stream chunks to Buffer before storing/counting keeps the in-memory store aligned with the byte-based contract.

      for await (const chunk of data as AsyncIterable<Buffer | string>) {
        if (chunk.length > 0) {
          chunks.push(chunk)
          count += chunk.length
        }

@copilot , please review the suppressed comments.
If that sounds good, let's make the appropriate changes.

[jainakanksha-msft]

@copilot , please review the suppressed comments.
If that sounds good, let's make the appropriate changes.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/common/persistence/MemoryExtentStore.ts:181

• appendExtent() now normalizes all stream chunks to Buffer, but chunks is still typed as (Buffer | string)[]. Narrowing this local type to Buffer[] better reflects the new invariant and avoids accidentally reintroducing string-length (character) semantics in future edits.

  async appendExtent(data: NodeJS.ReadableStream | Buffer, contextId?: string | undefined): Promise<IExtentChunk> {
    const chunks: (Buffer | string)[] = []
    let count = 0;
    if (Buffer.isBuffer(data)) {

[jainakanksha-msft]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)
src/common/persistence/MemoryExtentStore.ts:181

• appendExtent() now normalizes all stream chunks to Buffer, but chunks is still typed as (Buffer | string)[]. Narrowing this local type to Buffer[] better reflects the new invariant and avoids accidentally reintroducing string-length (character) semantics in future edits.

  async appendExtent(data: NodeJS.ReadableStream | Buffer, contextId?: string | undefined): Promise<IExtentChunk> {
    const chunks: (Buffer | string)[] = []
    let count = 0;
    if (Buffer.isBuffer(data)) {

@copilot , please review the suppressed comments.
If that sounds good, let's make the appropriate changes.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.

...

Agreed, narrowed chunks to Buffer[] in both IMemoryExtentChunk and the local variable in appendExtent() (6acee40 built on top). Build and tests pass.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 9 changed files in this pull request and generated no new comments.