[BUG]: Type Mismatch in `stats/base/cumax` Tests After Refactor to Generic Types

[deepak427]

Description

Encountered an error when ran typescript declaration test in @stdlib/stats/base/cumax.

After the commit feat: add support for accessor arrays and refactor stats/base/cumax, the cumax function was refactored to use generic types.
Previously, the output type was broadly defined as NumericArray. After the refactor, the return type of the function now depends on the type of the input array y. For example, if the input y is a Float64Array, the expected type should also be Float64Array instead of the broader NumericArray type.

Even though Float64Array is a subtype of NumericArray, when using generics, the return type is strictly inferred based on the specific input type provided.
This has led to type mismatches in the type declaration tests.

Related Issues

No response

Questions

No.

Demo

No response

Reproduction

- To reproduce this issue:
- Run shell command
make lint-typescript-declarations-tests TYPESCRIPT_DECLARATIONS_TESTS_FILTER=".*/stats/base/cumax/.*"

Expected Results

The test should be passed without any error.

Actual Results

Linting file: /workspaces/stdlib/lib/node_modules/@stdlib/stats/base/cumax/docs/types/test.ts

30:2  error  Expected type to be: NumericArray, got: Float64Array  expect-type/expect
128:2 error  Expected type to be: NumericArray, got: Float64Array  expect-type/expect

✖ 2 problems (2 errors, 0 warnings)

Version

No response

Environments

N/A

Browser Version

No response

Node.js / npm Version

No response

Platform

No response

Checklist

• Read and understood the Code of Conduct.
• Searched for existing issues and pull requests.

[deepak427]

This issue can be resolved by updating the type expectations in the test file to match the specific type of the input array y. Since the cumax function now uses generics, the return type is strictly inferred from the type of the input. Therefore, when y is a Float64Array, the expected output should also be a Float64Array rather than the broader NumericArray. Updating the expectType assertions accordingly will resolve the type mismatch errors.