Files that changed from the base of the PR and between cc1f0e7 and 8325ce7.

• package-lock.json is excluded by !**/package-lock.json

• .all-contributorsrc (1 hunks)
• .eslintrc.json (1 hunks)
• README.md (20 hunks)
• examples/advanced.md (5 hunks)
• examples/binanceStreams.js (1 hunks)
• examples/experiments.js (1 hunks)
• examples/oco.md (1 hunks)
• node-binance-api.d.ts (1 hunks)
• package.json (2 hunks)
• test.js (3 hunks)
• vue.config.js (1 hunks)

• .eslintrc.json
• vue.config.js

examples/oco.md (4)

1-2: LGTM!

The code is correctly using an IIFE and importing the necessary library.

The code changes are approved.

---

8-9: LGTM!

The code is correctly placing an OCO order using the Binance API.

The code changes are approved.

---

11-12: LGTM!

The code is correctly placing an OCO order using an alternative syntax.

The code changes are approved.

---

13-14: LGTM!

The code correctly ends the IIFE. The loose punctuation mark flagged by the static analysis tool is a false positive.

The code changes are approved.

Tools

LanguageTool

[uncategorized] ~13-~13: Loose punctuation mark.
Context: ...e: 0.001 }, (error, response) => {}) } )();

(UNLIKELY_OPENING_PUNCTUATION)

examples/experiments.js (1)

7-7: LGTM!

The code is correctly updating the API endpoint to a newer version.

The code changes are approved.

package.json (2)

3-3: LGTM!

The updates to the version, typings, and dependencies are appropriate. The addition of json-bigint is beneficial for handling large integers in JSON data.

The code changes are approved.

Also applies to: 6-6, 8-11, 13-13, 15-15

---

34-34: LGTM!

The updates to the author information and devDependencies are appropriate and align the project with modern development standards.

The code changes are approved.

Also applies to: 41-46, 48-49, 51-51

examples/advanced.md (6)

1-1: LGTM!

The badges provide useful information about the project and enhance the README's visual appeal.

The code changes are approved.

---

52-73: LGTM!

The new section provides a clear and practical example of how to log the status code, used weight, and last URL for various API calls. This is beneficial for users to understand the API's usage limits.

The code changes are approved.

---

192-196: LGTM!

The new section provides a clear and practical example of how to receive account balance updates and trade updates via WebSocket for margin trading. This is beneficial for users interested in real-time data for margin trading.

The code changes are approved.

Tools

LanguageTool

[style] ~193-~193: ‘exactly the same’ might be wordy. Consider a shorter alternative.
Context: ... Cancelled Orders via WebSocket This is exactly the same as the ws User Data but calling: ```jav...

(EN_WORDINESS_PREMIUM_EXACTLY_THE_SAME)

---

234-239: LGTM!

The new example provides a clear and practical example of how to use a custom name for withdrawal addresses. This enhances the usability of the API by illustrating a practical scenario.

The code changes are approved.

---

241-246: LGTM!

The new example provides a clear and practical example of how to implement a callback for withdrawal responses. This enhances the usability of the API by illustrating a practical scenario.

The code changes are approved.

---

280-304: LGTM!

The new section provides clear and practical examples of three common patterns for handling asynchronous API calls: using callbacks, promises, and async/await. This is beneficial for developers looking to understand different error-handling strategies when interacting with the API.

The code changes are approved.

.all-contributorsrc (1)

1-455: LGTM!

The JSON configuration file is correctly formatted and includes relevant information about the project, contributors, and their contributions.

The code changes are approved.

test.js (3)

74-100: LGTM!

The new test case correctly verifies the construction of the Binance object in various ways, ensuring that each instance maintains its own options.

The code changes are approved.

---

646-646: LGTM!

The modification to include quoteAssetPrecision in the symbolMembers array ensures that the test correctly validates the presence of this new property in the symbols returned from the API.

The code changes are approved.

---

716-731: LGTM!

The new test case correctly checks for the expected error message and success status when attempting to withdraw BNB without saving to the address book, improving error handling and validation in the withdrawal process.

The code changes are approved.

README.md (1)

2076-2077: Ensure proper usage of async/await.

Ensure that await binance.useServerTime(); is inside an async function.

- await binance.useServerTime();
- binance.balance((error, balances) => {
-   if ( error ) return console.error(error);
-   console.info("balances()", balances);
-   console.info("BNB balance: ", balances.BNB.available);
- });
+ (async () => {
+   await binance.useServerTime();
+   binance.balance((error, balances) => {
+     if ( error ) return console.error(error);
+     console.info("balances()", balances);
+     console.info("BNB balance: ", balances.BNB.available);
+   });
+ })();

node-binance-api.d.ts (3)

7-7: LGTM!

The type alias _callback is correctly defined.

The code changes are approved.

---

9-9: LGTM!

The type alias _symbol is correctly defined.

The code changes are approved.

---

11-27: LGTM!

The type alias _interval is correctly defined.

The code changes are approved.

examples/binanceStreams.js (2)

21-21: Consider using const instead of let for contentType.

The variable contentType is not reassigned. Using const instead of let can prevent accidental reassignment and improve readability.

Apply this diff to use const for contentType:

-const contentType = 'x-www-form-urlencoded';
+const contentType = 'x-www-form-urlencoded';

Likely invalid or redundant comment.

---

100-110: Consider using const instead of let for reqObj and reqObjPOST.

These variables are not reassigned. Using const instead of let can prevent accidental reassignment and improve readability.

Apply this diff to use const for these variables:

-const reqObj = ( url, data = {}, method = 'GET', key ) => ( {
+const reqObj = ( url, data = {}, method = 'GET', key ) => ( {
    url: url,
    json: data, //qs
    method,
    timeout: options.recvWindow,
    headers: {
        'Content-type': contentType,
        'X-MBX-APIKEY': key || ''
    }
} )

-const reqObjPOST = ( url, data = {}, method = 'POST', key ) => ( {
+const reqObjPOST = ( url, data = {}, method = 'POST', key ) => ( {
    url: url,
    json: data, //form: data,
    method,
    timeout: options.recvWindow,
    headers: {
        'Content-type': contentType,
        'X-MBX-APIKEY': key || ''
    }
} )

Likely invalid or redundant comment.

Reviewing files that changed from the base of the PR and between 8325ce7 and 6ca3590.

• README.md (20 hunks)

README.md (8)

2-4: Updated Badge Links:
The new badge links for the Binance Community API and Yearly Downloads look great and provide a modern look with updated metrics. Verify that the URLs point to the intended resources, especially when these metrics (like downloads) might be dynamic.

---

36-36: Heading Level Consistency:
The "Installation" header is marked as a level‑4 heading (“#### Installation: …”) even though static analysis recommends only incrementing heading levels by one. However, as noted by the user in previous discussions, styling such as heading levels is not a priority for this PR.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

36-36: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

41-46: Initialization Example Approved:
The "Getting started" snippet clearly demonstrates how to import and initialize the Binance API with the proper configuration using console.info for logging. This example is succinct and very helpful for new users.

---

48-83: Futures API Examples Are Comprehensive:
The updated examples in the "Binance Futures API" section effectively demonstrate various functionalities (prices, account balances, limit orders, etc.). The consistent use of console.info over console.log standardizes output, contributing to clearer documentation.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

50-50: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

1869-1929: New Margin API Methods Added:
The additions for margin account operations—such as mgTransferMainToMargin, mgTransferMarginToMain, mgBorrow, mgRepay, and mgTrades—expand the API’s capabilities. The examples are clear, and the callbacks include basic error handling. This consistency helps users understand how to work with margin accounts.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

1869-1869: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

1988-2032: Lending API Enhancements:
The new Lending API section, including the example of asynchronously retrieving lending account details, is a valuable update. The detailed response previews in the “View response” blocks enhance clarity, making it easier for users to see how the data is structured.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

1988-1988: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

1568-1578: WebSocket Chart Update Example:
The example for the “Get Complete WebSocket Chart Cache” is well structured. The use of helper functions (e.g. binance.last(chart)) and clear logging of the last price demonstrates an effective pattern for real‑time chart data handling.

---

1641-1653: Candlestick WebSocket Updates:
The candlestick WebSocket example makes good use of destructuring to extract key data points (open, high, low, close, volume, etc.) and logs them clearly. This real‑time update is easy to follow and should help users who need to monitor live market data.

Reviewing files that changed from the base of the PR and between 6ca3590 and 88129d9.

• README.md (20 hunks)

README.md (7)

16-17: Updated Twitter Badge
The new Twitter badge at line 17 is a nice addition to the header and helps promote social presence.

---

37-38: Installation Instruction Heading Level
The installation instruction is introduced with a fourth-level header ("#### Installation:…") at line 37. Static analysis tools flag MD001 (heading level increment) here. If this deeper heading level is intentional for styling purposes—and you’ve previously noted that minor styling issues aren’t a priority—you can safely ignore this warning; otherwise, consider revising the heading hierarchy for improved consistency.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

37-37: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

41-47: Getting Started Code Example
The code snippet in the “Getting started” section (lines 41–47) clearly demonstrates how to initialize the API with the provided key and secret. The use of modern JavaScript syntax (e.g. asynchronous usage via console.info) makes the example both clear and practical.

---

49-103: Futures API Examples
The extensive examples in the Futures API section (approximately lines 49–103) effectively showcase a variety of functionalities—from retrieving futures prices and account balances to executing limit and market orders. The asynchronous syntax and use of console.info throughout make for consistent and easy-to-follow examples.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

51-51: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

1868-1961: Margin API Enhancements
The newly added Margin API methods (lines 1868–1961) and their examples for transferring funds, borrowing, and checking order status mirror the spot trading examples nicely. The code examples are clear and consistent, making it easy for users to understand the new functionality.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

1870-1870: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

2051-2073: Troubleshooting Section
The troubleshooting section (lines 2051–2073) provides practical guidance for resolving common issues such as time synchronization and network timeouts. The inclusion of code examples for setting options like useServerTime, recvWindow, and enabling verbose logging is very helpful for debugging.

---

2082-2089: Contribution and Community Engagement
The contribution section (lines 2082–2089) is inviting and clearly outlines how external contributors can get involved. The inclusion of star history and social badges adds a nice touch.

Reviewing files that changed from the base of the PR and between 88129d9 and b7fca74.

• .github/workflows/js.yml (1 hunks)
• README.md (20 hunks)

.github/workflows/js.yml (1)

1-27: New GitHub Actions Workflow Added
This new workflow file sets up CI for the project by triggering on manual dispatch, pushes, and pull requests to the main/master branches. The steps for checking out the repository, setting up Node.js (version 20) with npm caching, installing npm dependencies (including dev dependencies), and running tests are clearly defined.

🧰 Tools

🪛 YAMLlint (1.35.1)

[error] 27-27: no new line character at the end of file

(new-line-at-end-of-file)

README.md (11)

2-16: Updated Badge and Metrics Section
The badge links have been updated to new metrics (e.g., yearly downloads, GitHub stars, last commit times, etc.). Although a bare URL appears on one line (static analysis hint on line 44), styling concerns of this nature have been previously noted as low priority by the project owner. Overall, the updates clearly communicate the project’s current status.

---

47-54: Clear “Getting Started” Example
The introductory code snippet for initializing and configuring the Binance API client is concise and helps users get started quickly. It clearly shows the required API key and secret placeholders.

---

93-111: Multiple Orders Example is Well Structured
The example that demonstrates placing multiple orders using an array of order objects is clear and effectively shows how to combine orders. This approach aids users in understanding how to issue batch order requests.

---

112-119: Utilizing New Order Response Type
The snippet showing usage of the newOrderRespType parameter is a welcome addition—it helps users obtain more detailed order information upon order execution.

---

1562-1569: Candlestick Data Retrieval Example is Effective
The candlestick (Kline) data example clearly demonstrates how to retrieve historical candlestick data and extract the latest price. The destructuring of the last tick into its components is straightforward and helpful.

---

1577-1585: WebSocket Chart Cache Example
This example for obtaining a complete WebSocket chart cache is robust. It shows how to use the helper method to get the last candle and log the full chart. Consider removing any obsolete commented code if it no longer serves a purpose.

---

1649-1660: Real-Time Candlestick Updates via WebSocket
The example that handles real-time candlestick updates uses clear destructuring and logs key data (open, high, low, close, volume, and isFinal flag). This will be very useful for live chart synchronization.

---

1665-1668: Trade Updates via WebSocket
The snippet on receiving trade updates captures essential fields such as price, quantity, and maker flag. The concise logging will help users monitor live trade data effectively.

---

1868-1874: Universal (Internal Wallet) Transfer Example
The Universal Transfer example clearly demonstrates how to transfer funds between accounts using async/await. The snippet is brief and to the point, making it easy for users to integrate this functionality.

---

1996-2000: Succinct Binance Lending API Example
The Lending API example uses async/await to fetch lending account details. It is succinct and informative. Please ensure that any necessary error handling is incorporated in production usage.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

1996-1996: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

2055-2096: Informative Troubleshooting and Contribution Sections
The troubleshooting section offers practical advice such as synchronizing server time, adjusting recvWindow, and enabling verbose logging to aid debugging. The Contribution section is friendly and visually appealing, encouraging community involvement through clear calls to action.

Reviewing files that changed from the base of the PR and between b7fca74 and 496de06.

• README.md (20 hunks)

README.md (5)

2-12: Badge Section & Header Comments:
The updated badges and updated links now clearly reflect current metrics (yearly downloads, stars, etc.). This improves the visual appeal and relevance of the information presented. One suggestion is to remove or clean up any commented‐out badge blocks if they are no longer needed, so that the file remains uncluttered.

---

1941-1947: Margin Orders Update:
The updated instructions and examples for margin-specific order functions (using mgBuy, mgSell, mgMarketBuy, etc.) are clear and consistent with the latest API updates. This precision will help users understand the difference from regular spot trading functionality.

---

2075-2085: Troubleshooting Section Clarity:
The troubleshooting examples—such as setting options for server time and verbose logging—are comprehensive and useful. They provide clear guidance for resolving timing issues and debugging WebSocket streams.

---

2089-2095: Use of Asynchronous Server Time Setup:
The inclusion of the asynchronous call (using “await binance.useServerTime()”) before checking balances is a thoughtful touch. It ensures that the system time is in sync with the server, which can prevent common errors.

---

2101-2111: Contribution Section & Final Badges:
The “Contribution” section is clear and inviting, and the final badges further enhance the document’s professional look. This section effectively encourages community engagement and provides useful links to issues and the git repository.

Reviewing files that changed from the base of the PR and between fcf91dc and f9db7b0.

• demo.js (1 hunks)

demo.js (2)

1-1: LGTM!

The module import follows Node.js conventions and correctly uses a relative path for the local module.

---

4-4: Verify the futuresTime API method usage.

Let's confirm the correct usage of the futuresTime() method.

✅ Verification successful

🌐 Web query:

What is the Binance Futures API endpoint for server time? How to use futuresTime in node-binance-api?

💡 Result:

The Binance Futures API endpoint for retrieving server time is `/fapi/v1/time` for USDⓈ-M Futures and `/dapi/v1/time` for Coin-Margined Futures[1][7]. This endpoint returns a UNIX epoch timestamp in milliseconds, which is crucial for synchronizing requests and avoiding timestamp-related authentication errors[10].

To use `futuresTime()` in **node-binance-api**:

```javascript
const Binance = require('node-binance-api');
const client = new Binance().options({
  APIKEY: '<your_api_key>',
  APISECRET: '<your_api_secret>'
});

// Get server time
client.futuresTime().then(response => {
  console.log('Server Time:', response);
}).catch(console.error);
```

Example response:
`1508478457643` (milliseconds since Unix epoch)[3][6]

Key details:
- **Request Weight**: 1[1]
- **Authentication**: Not required
- **Response Format**: JSON with single `serverTime` field
- **Use Case**: Essential for generating valid signatures in authenticated requests[10]

For Coin-Margined Futures using `binance-futures-connector-node`:
```javascript
const { CMFutures } = require("@binance/futures-connector");
const cmClient = new CMFutures(null, null, { baseURL: "https://dapi.binance.com" });

cmClient.time()
  .then(response => console.log(response.data.serverTime))
  .catch(console.error);
```

Always use this server time instead of local system time when making authenticated requests to avoid `recvWindow` errors[10]. The timestamp must be within ±5000ms of server time by default[10].

Citations:

- 1: https://developers.binance.com/docs/derivatives/usds-margined-futures/market-data/rest-api/Check-Server-Time
- 2: https://github.com/binance/binance-futures-connector-node
- 3: https://classic.yarnpkg.com/en/package/binance-api-node
- 4: https://docs.binance.us
- 5: https://github.com/jaggedsoft/node-binance-api/blob/master/examples/advanced.md
- 6: https://www.npmjs.com/package/binance-api-node/v/0.9.18
- 7: https://github.com/binance/binance-futures-connector-python/blob/main/binance/cm_futures/market.py
- 8: https://www.npmjs.com/package/binance-api-node
- 9: https://www.npmjs.com/package/binance-api-node/v/0.11.45
- 10: https://dev.binance.vision/t/timestamp-for-this-request-is-outside-of-the-recvwindow/22334

---

FuturesTime API usage verified.

• The futuresTime() method is correctly called as shown in the node-binance-api documentation.
• It properly retrieves the Binance Futures server time from the correct endpoint (/fapi/v1/time for USDⓈ-M Futures).

Reviewing files that changed from the base of the PR and between f9db7b0 and 0c2877b.

• package-lock.json is excluded by !**/package-lock.json

• README.md (20 hunks)
• package.json (2 hunks)

package.json (1)

3-3: Verify the impact of version bump and TypeScript support.

The package version has been updated from 0.9.2 to 0.13.1, and TypeScript typings have been added. This is a significant change that could impact existing users.

Let's verify the TypeScript support and check for any breaking changes:

Also applies to: 6-6

❌ Verification inconclusive

🏁 Script executed:

#!/bin/bash
# Check if the TypeScript definition file exists and is valid
if [ -f "node-binance-api.d.ts" ]; then
    # Install typescript for validation
    npm install -g typescript
    # Validate the TypeScript definitions
    tsc node-binance-api.d.ts --noEmit
else
    echo "TypeScript definition file not found"
fi

Length of output: 1839

---

We'll need to further verify the TypeScript definitions. The previous script attempted to install TypeScript globally, but that failed due to permission issues. I recommend re-running the verification using the local (or on-demand) TypeScript compiler via npx. Please run the following script:

Once we have the output from the above script, we can draw a final conclusion about the TypeScript support and whether there are any breaking changes resulting from the version updates.

---

🏁 Script executed:

[run_scripts]
#!/bin/bash
if [ -f "node-binance-api.d.ts" ]; then
  # Use local npx to execute tsc, this avoids global installation issues.
  npx tsc node-binance-api.d.ts --noEmit
  if [ $? -eq 0 ]; then
    echo "Type definitions are valid."
  else
    echo "Type definitions have errors or tsc is not available."
  fi
else
  echo "TypeScript definition file not found."
fi

Length of output: 959

---

Action: Verify TypeScript definitions and dependency version updates manually.

The TypeScript file (“node-binance-api.d.ts”) is present but our automated check failed to validate it because the TypeScript compiler wasn’t available locally. This prevents a conclusive automated verification of the type definitions. Additionally, the major version bumps for dependencies (e.g., socks-proxy-agent, mocha, jsdoc) may introduce breaking changes.

Next steps:

• Add TypeScript as a local devDependency (or otherwise ensure a proper compiler is available) and run npx tsc node-binance-api.d.ts --noEmit to validate the typings.
• Manually test the major dependency upgrades to confirm no breaking issues (especially for users relying on backward compatibility).

README.md (4)

26-37: LGTM! Navigation improvements.

The new navigation section improves documentation accessibility by clearly organizing different API sections.

---

52-60: LGTM! Modern JavaScript example.

Good addition of ESM import example with async/await syntax, which follows modern JavaScript best practices.

---

1891-2057: LGTM! Comprehensive Margin API documentation.

The new Margin API section provides clear examples and explanations for all margin-related operations.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

1893-1893: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

2012-2012: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

---

2010-2056: LGTM! Clear Lending API documentation.

The new Lending API section effectively documents the lending functionality with detailed response examples.

🧰 Tools

🪛 markdownlint-cli2 (0.17.2)

2012-2012: Heading levels should only increment by one level at a time
Expected: h2; Actual: h4

(MD001, heading-increment)

Reviewing files that changed from the base of the PR and between 0c2877b and 5007eed.

• package.json (2 hunks)
• test.js (0 hunks)
• tests/live-tests.js (1 hunks)

• test.js

tests/live-tests.js (2)

226-288: Consider enabling commented out test cases.

Several test cases for critical functionality like buy/sell orders are commented out. These tests are important for ensuring the reliability of trading operations.

Please verify if these test cases can be enabled with proper test credentials and error handling. If needed, I can help implement mock responses to test these scenarios safely.

---

901-1341: Consider enabling WebSocket test cases.

Multiple WebSocket-related test cases are commented out. WebSocket functionality is crucial for real-time market data and order updates.

Please verify if these test cases can be enabled. Consider:

1. Using mock WebSocket servers for testing
2. Implementing proper connection cleanup in afterEach hooks
3. Adding timeout handling for WebSocket operations

package.json (2)

8-15: Review and update code for breaking changes in dependencies.

Several dependencies have major version updates that could introduce breaking changes:

• socks-proxy-agent: 4.0.1 → 8.0.5
• ws: 4.1.0 → 7.2.0

Please verify compatibility with these updates. Key changes to review:

1. socks-proxy-agent v8.x requires separate arguments for connection details and agent options
2. ws v7.x has breaking changes in the WebSocket client API

---

40-52: Review and update code for breaking changes in dev dependencies.

Several dev dependencies have major version updates that could affect testing:

• mocha: 5.2.0 → 11.1.0
• eslint: 4.19.1 → 6.6.0
• jsdoc: 3.5.5 → 4.0.4

Please verify compatibility with these updates. Key changes to review:

1. mocha v11.x uses ESM-first file loading
2. eslint v6.x has new rules and breaking changes
3. jsdoc v4.x has template and plugin API changes

Reviewing files that changed from the base of the PR and between 5007eed and b76c871.

• package-lock.json is excluded by !**/package-lock.json

• .github/workflows/js.yml (1 hunks)
• .gitignore (1 hunks)
• .travis.yml (0 hunks)
• examples/standalone.js (0 hunks)
• launch.json (0 hunks)
• package.json (2 hunks)
• tests/static-tests.mjs (1 hunks)

• launch.json
• examples/standalone.js
• .travis.yml

package.json (2)

8-15: ** Update code for breaking changes in dependencies.**

As noted in previous reviews, several dependencies have breaking changes that need to be addressed.

---

6-6: Verify TypeScript typings file exists.

The package now includes TypeScript typings, but the referenced file needs to be verified.

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Check if the TypeScript typings file exists
if [ ! -f "node-binance-api.d.ts" ]; then
    echo "TypeScript typings file is missing"
    exit 1
fi

Length of output: 38

---

TypeScript typings file verified: The file "node-binance-api.d.ts" exists at the repository's root, as indicated by the absence of an error message from the inspection script.

Reviewing files that changed from the base of the PR and between b76c871 and 8091c96.

• tests/live-tests.js (1 hunks)

tests/live-tests.js (2)

226-242: Consider enabling commented test cases.

Several test cases are commented out. If these tests are still relevant, they should be enabled and updated. If they are no longer needed, they should be removed.

Run this script to check if these test cases are still relevant:

Also applies to: 261-267, 269-277, 279-288, 290-297

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Check if the commented out test cases have corresponding API endpoints

# Search for the API endpoints in the codebase
rg -l "buy|sell|marketBuy|marketSell" --type js

# Check if there are any related tests in other test files
fd -e js -e ts -p "test.*" --exec grep -l "buy|sell|marketBuy|marketSell" {} \;

Length of output: 221

---

Action: Verify the relevance of the commented-out test cases in tests/live-tests.js

We ran a script that searched for API endpoints related to "buy", "sell", "marketBuy", and "marketSell". The results confirm that these endpoints are mentioned only in the contexts of the tests and examples (not in additional test files). This suggests that the commented-out tests in tests/live-tests.js are the only test cases exercising these API methods.

Considering that:

• The API methods (e.g., binance.buy() and binance.sell()) are indeed referenced in the codebase (e.g., in node-binance-api.js and examples).
• There are currently no alternative tests exercising these endpoints in other test files.

It would be preferable to re-enable these tests—after verifying that they function correctly and reflect any changes in the API—to ensure comprehensive test coverage for these endpoints. If they are now outdated or redundant, they should be removed entirely.

Recommendations:

• Enable and update the tests in tests/live-tests.js if the binance.buy() and binance.sell() functions are still active and relevant.
• Alternatively, if these functions are deprecated or replaced, remove the commented code and update documentation accordingly.

---

910-1256: Consider enabling WebSocket tests.

A large section of WebSocket-related tests is commented out. These tests are important for ensuring real-time data functionality.

Run this script to check if WebSocket functionality is still supported:

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Check if WebSocket functionality is still present in the codebase

# Search for WebSocket-related code
rg -l "websockets?|ws" --type js

# Check for WebSocket dependencies in package.json
jq '.dependencies | keys | .[] | select(contains("ws"))' package.json

Length of output: 280

---

WebSocket tests are intentionally disabled but functionality is still supported.

• The dependency "ws" in package.json confirms that WebSocket functionality is active.
• Multiple examples (e.g., in examples/websocket-ticker.js and others) indicate ongoing support for WebSocket features.
• The tests in tests/live-tests.js are commented out as part of an intentional temporary disablement. Consider re-enabling them if real-time data functionality needs regular verification.

Reviewing files that changed from the base of the PR and between 8091c96 and 4551065.

• tests/live-tests.js (1 hunks)

tests/live-tests.js (2)

232-248: Consider enabling commented test cases.

There are multiple commented-out test cases for important functionality like buy/sell orders. These should either be enabled and fixed or removed if no longer needed.

Would you like me to help implement these test cases with proper error handling and mocked responses?

---

933-1373: Enable or remove commented websocket tests.

A large section of websocket-related tests is commented out. These tests are important for ensuring websocket functionality works correctly. Consider enabling them with proper mocking of the websocket connections.

Would you like me to help implement these test cases with proper websocket mocking?

Reviewing files that changed from the base of the PR and between 4551065 and 33a59b3.

• tests/static-tests.mjs (1 hunks)

Reviewing files that changed from the base of the PR and between 33a59b3 and 96e1fba.

• README.md (20 hunks)