bot, jobs,tests/bot: convert requires to imports #638
Conversation
Converted requires to imports where applicable and fixed type errors resulting from it.
They are used to typecheck .js files, but make no sense in .ts files as they are already type-checked.
WalkthroughThis update transitions the codebase from using the legacy Changes
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (4)
bot/start.ts (4)
220-237: 🛠️ Refactor suggestionNon-null assertion and context type inconsistency.
This handler has two issues:
- It uses a non-null assertion on the result of
validateParamswithout explicitly checking for null.- It still uses
MainContextinstead ofCommunityContext.- bot.command('maintenance', superAdminMiddleware, async (ctx: MainContext): Promise<void> => { + bot.command('maintenance', superAdminMiddleware, async (ctx: CommunityContext): Promise<void> => { try { - const [val] = (await validateParams(ctx, 2, '\\<_on/off_\\>'))!; - if (!val) return; + const validatedParams = await validateParams(ctx, 2, '\\<_on/off_\\>'); + if (!validatedParams) return; + const [val] = validatedParams; + if (!val) return;
252-259: 🛠️ Refactor suggestionContext type inconsistency and CommonJS require usage.
This handler has two issues:
- It still uses
MainContextinstead ofCommunityContext.- It uses CommonJS
requireinstead of ES6 import.- bot.command('version', async (ctx: MainContext) => { + bot.command('version', async (ctx: CommunityContext) => { try { - const pckg = require('../../package.json'); + // Consider importing package.json at the top of the file + // but since it's a one-time use, this approach is acceptable + const pckg = require('../../package.json'); await ctx.reply(pckg.version);
291-324: 🛠️ Refactor suggestionNon-null assertion and context type inconsistency.
Similar issues as observed in previous handlers:
- Non-null assertion without explicit null check.
MainContextinstead ofCommunityContext.- bot.command('freezeorder', adminMiddleware, async (ctx: MainContext) => { + bot.command('freezeorder', adminMiddleware, async (ctx: CommunityContext) => { try { - const [orderId] = (await validateParams(ctx, 2, '\\<_order id_\\>'))!; + const validatedParams = await validateParams(ctx, 2, '\\<_order id_\\>'); + if (!validatedParams) return; + const [orderId] = validatedParams;
531-570: 🛠️ Refactor suggestionContext type inconsistency and non-null assertion.
Similar to previous comments, this handler:
- Uses
MainContextinstead ofCommunityContext.- Uses non-null assertion without explicit null check.
- bot.command('checkorder', superAdminMiddleware, async (ctx: MainContext) => { + bot.command('checkorder', superAdminMiddleware, async (ctx: CommunityContext) => { try { - const [orderId] = (await validateParams(ctx, 2, '\\<_order id_\\>'))!; + const validatedParams = await validateParams(ctx, 2, '\\<_order id_\\>'); + if (!validatedParams) return; + const [orderId] = validatedParams;
🧹 Nitpick comments (17)
app.ts (1)
5-5: Consider converting the remaining require statement.There's still a CommonJS require statement for resubscribeInvoices that could be converted to an ES module import for consistency.
-const { resubscribeInvoices } = require('./ln'); +import { resubscribeInvoices } from './ln';bot/modules/nostr/index.ts (2)
1-1: Consider converting the remaining require statement.There's still a CommonJS require statement for websocket-polyfill that could be converted to an ES module import for consistency.
-require('websocket-polyfill'); +import 'websocket-polyfill';
24-24: Consider converting the remaining require statement.There's still a CommonJS require statement for OrderEvents that could be converted to an ES module import for consistency.
-const OrderEvents = require('../events/orders'); +import * as OrderEvents from '../events/orders';jobs/cancel_orders.ts (4)
2-2: Redundant MainContext import.The MainContext is imported but never used in this file. You should remove it from the imports to maintain clean code.
-import { HasTelegram, MainContext } from "../bot/start"; +import { HasTelegram } from "../bot/start";
11-11: Consider updating function signature to match usage.The function now takes a
HasTelegramtype but immediately casts toCommunityContextin the implementation. Consider updating the parameter type to directly acceptTelegraf<CommunityContext>for better type safety and to avoid type assertions.-const cancelOrders = async (bot: HasTelegram) => { +const cancelOrders = async (bot: Telegraf<CommunityContext>) => {
34-34: Type casting could be avoided with proper parameter typing.Using type assertions (
as CommunityContext) indicates potential type incompatibility. This could be avoided by properly typing the function parameter.- await cancelShowHoldInvoice(bot as CommunityContext, order, true); + await cancelShowHoldInvoice(bot, order, true);Note: This change should be made after updating the function signature as suggested earlier.
36-36: Type casting could be avoided with proper parameter typing.Similar to the previous comment, this type assertion could be avoided with proper typing of the function parameter.
- await cancelAddInvoice(bot as CommunityContext, order, true); + await cancelAddInvoice(bot, order, true);Note: This change should be made after updating the function signature as suggested earlier.
jobs/pending_payments.ts (1)
6-9: Unused MainContext import.The
MainContextis imported but not used in the file. Consider removing it to maintain clean imports.-import { MainContext } from '../bot/start'; import { payRequest, isPendingPayment } from '../ln'; import { getUserI18nContext } from '../util'; import { CommunityContext } from '../bot/modules/community/communityContext';bot/start.ts (3)
207-218: Context type inconsistency.While many handlers have been updated to use
CommunityContext, this handler still usesMainContext. Consider updating this handler to useCommunityContextfor consistency.- bot.start(async (ctx: MainContext) => { + bot.start(async (ctx: CommunityContext) => {
239-250: Context type inconsistency.This handler still uses
MainContextinstead ofCommunityContext. Consider updating it for consistency.- bot.on('text', userMiddleware, async (ctx: MainContext, next: () => void) => { + bot.on('text', userMiddleware, async (ctx: CommunityContext, next: () => void) => {
326-393: Inconsistent null check pattern.This handler uses a different pattern for checking null values from
validateParamscompared to other handlers:const validatedParams = (await validateParams(ctx, 2, '\\<_order id_\\>'))!; if (validatedParams == null) return; const [orderId] = validatedParams;This is safer than just using non-null assertion, but inconsistent with other handlers. Consider standardizing the approach across all handlers.
- bot.command('cancelorder', adminMiddleware, async (ctx: MainContext) => { + bot.command('cancelorder', adminMiddleware, async (ctx: CommunityContext) => { try { - const validatedParams = (await validateParams(ctx, 2, '\\<_order id_\\>'))!; - if (validatedParams == null) return; - const [orderId] = validatedParams; + const validatedParams = await validateParams(ctx, 2, '\\<_order id_\\>'); + if (!validatedParams) return; + const [orderId] = validatedParams;bot/messages.ts (6)
376-376: Added non-null assertion operatorThe code now uses the non-null assertion operator
!withfiatAmountto address TypeScript's strict null checking. While this works, consider using optional chaining or a default value for a more defensive approach.- fiatAmount: numberFormat(fiatCode, fiatAmount!), + fiatAmount: numberFormat(fiatCode, fiatAmount ?? 0),
490-490: Similar non-null assertion usageAgain using the non-null assertion operator
!withorder.fiat_amount. Consider using optional chaining or a default value for more robust code.- fiatAmount: numberFormat(order.fiat_code, order.fiat_amount!), + fiatAmount: numberFormat(order.fiat_code, order.fiat_amount ?? 0),
863-863: Non-null assertion for fiat_amountUsing the non-null assertion operator
!withorder.fiat_amount. Consider using optional chaining or a default value for more defensive programming.- fiatAmount: numberFormat(order.fiat_code, order.fiat_amount!), + fiatAmount: numberFormat(order.fiat_code, order.fiat_amount ?? 0),
885-885: Another non-null assertion usageAgain using the non-null assertion operator
!withorder.fiat_amount. Consider using optional chaining or a default value for a more defensive approach.- fiatAmount: numberFormat(order.fiat_code, order.fiat_amount!), + fiatAmount: numberFormat(order.fiat_code, order.fiat_amount ?? 0),
1267-1267: Non-null assertion usageUsing the non-null assertion operator
!withorder.fiat_amount. Consider using optional chaining or a default value for more robust code.- fiatAmount: numberFormat(order.fiat_code, order.fiat_amount!), + fiatAmount: numberFormat(order.fiat_code, order.fiat_amount ?? 0),
1327-1327: Consistent non-null assertionUsing the non-null assertion operator
!withorder.fiat_amount. Consider using optional chaining or a default value for a more defensive approach.- fiatAmount: numberFormat(order.fiat_code, order.fiat_amount!), + fiatAmount: numberFormat(order.fiat_code, order.fiat_amount ?? 0),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
app.ts(2 hunks)bot/commands.ts(10 hunks)bot/index.ts(3 hunks)bot/messages.ts(27 hunks)bot/middleware/stage.ts(1 hunks)bot/middleware/user.ts(3 hunks)bot/modules/community/commands.ts(0 hunks)bot/modules/community/index.ts(1 hunks)bot/modules/community/scenes.communityAdmin.ts(1 hunks)bot/modules/community/scenes.ts(1 hunks)bot/modules/dispute/actions.ts(1 hunks)bot/modules/dispute/commands.ts(1 hunks)bot/modules/dispute/index.ts(1 hunks)bot/modules/events/community.ts(0 hunks)bot/modules/events/orders.ts(0 hunks)bot/modules/language/index.ts(1 hunks)bot/modules/nostr/index.ts(1 hunks)bot/modules/orders/commands.ts(0 hunks)bot/modules/orders/index.ts(1 hunks)bot/modules/orders/takeOrder.ts(1 hunks)bot/modules/user/index.ts(1 hunks)bot/ordersActions.ts(1 hunks)bot/scenes.ts(1 hunks)bot/start.ts(22 hunks)bot/validations.ts(1 hunks)jobs/cancel_orders.ts(2 hunks)jobs/communities.ts(1 hunks)jobs/delete_published_orders.ts(2 hunks)jobs/node_info.ts(1 hunks)jobs/pending_payments.ts(2 hunks)
💤 Files with no reviewable changes (4)
- bot/modules/events/community.ts
- bot/modules/events/orders.ts
- bot/modules/orders/commands.ts
- bot/modules/community/commands.ts
✅ Files skipped from review due to trivial changes (12)
- bot/modules/community/scenes.communityAdmin.ts
- bot/modules/orders/takeOrder.ts
- bot/validations.ts
- bot/modules/community/index.ts
- bot/modules/dispute/actions.ts
- bot/scenes.ts
- bot/modules/user/index.ts
- bot/ordersActions.ts
- bot/modules/orders/index.ts
- bot/modules/community/scenes.ts
- bot/modules/dispute/commands.ts
- bot/middleware/stage.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Analyze (javascript)
🔇 Additional comments (70)
bot/index.ts (3)
1-3: Syntax modernization successfully implemented.The conversion from CommonJS requires to ES6 imports is correctly implemented here. This aligns with the PR objectives to modernize the code.
13-37: Imports properly structured with named exports.The ES6 import syntax is correctly implemented with named exports, maintaining code structure while modernizing the syntax.
39-76:❓ Verification inconclusive
Verify removal of beginDisputeMessage from exports.
The export statement now uses ES6 syntax which is correct, but I notice that
beginDisputeMessagehas been removed from the exports. Ensure this is intentional and won't break any code that might be depending on this export.
🏁 Script executed:
#!/bin/bash # Search for any usages of beginDisputeMessage in the codebase echo "Searching for usages of beginDisputeMessage in the codebase..." rg "beginDisputeMessage" --type ts --type jsLength of output: 179
Action Required: Manually Verify Removal of beginDisputeMessage
I ran a search for any occurrences of
beginDisputeMessageacross TypeScript/JavaScript files, and no references were found. This confirms that its removal from the export inbot/index.tsappears to be intentional. However, please manually verify that no external dependencies (including tests or client integrations) rely on this export before finalizing the merge.
- File:
bot/index.ts
- Export removal appears intentional, but double-check external dependencies.
jobs/communities.ts (2)
5-5: Import for CommunityContext properly added.The import for
CommunityContextis correctly added to support the type change in the function parameter.
7-7: Type signature updated to use CommunityContext.The function signature update from
MainContexttoCommunityContextaligns with the broader transition in the codebase.Consider running the following to verify that this change is consistent across the entire application:
#!/bin/bash # Check for any remaining usages of MainContext that might need updating echo "Checking for remaining MainContext usages that might need updating..." rg "MainContext" --type tsbot/modules/dispute/index.ts (2)
4-5: Middleware imports modernized correctly.The conversion from CommonJS requires to ES6 imports for middleware is done correctly, and the
CommunityContextimport is properly added.
7-7: Bot parameter type updated to CommunityContext.The function signature update is consistent with the pattern being applied across the codebase, changing from
MainContexttoCommunityContext.bot/modules/language/index.ts (3)
1-1: Middleware import modernized correctly.The conversion from CommonJS require to ES6 import for userMiddleware is correctly implemented.
6-6: CommunityContext import properly added.The import for
CommunityContextis correctly added to support the type change in the function signature.
8-8: Export syntax and type signature modernized.The function signature has been updated from
exports.configuretoexport const configureand the type has been changed fromTelegraftoTelegraf<CommunityContext>, which aligns with the PR objectives.jobs/node_info.ts (3)
4-4: Correctly migrated to use CommunityContext.This import change is aligned with the PR objective to modernize the code, switching from MainContext to the new CommunityContext type.
6-6: Properly converted require to import statement.Good job converting the CommonJS require syntax to ES module import syntax for the logger, which aligns with the PR objectives.
8-8: Updated function signature to use CommunityContext.The type of the bot parameter has been correctly updated from MainContext to CommunityContext, maintaining type safety while modernizing the codebase.
app.ts (3)
3-3: Properly converted require to import statement.Good job converting the CommonJS require syntax to ES module import syntax for the start function.
8-9: Properly converted require to import statements and added CommunityContext.Good job converting the CommonJS require syntax to ES module import syntax for the delay utility and adding the necessary CommunityContext import.
28-28: Updated options type to use CommunityContext.The type for the options variable has been correctly updated to use CommunityContext instead of MainContext, maintaining type consistency with the rest of the application.
bot/modules/nostr/index.ts (2)
8-9: Properly converted require to import statements and added CommunityContext.Good job converting the CommonJS require syntax to ES module import syntax for CommunityEvents and adding the necessary CommunityContext import.
11-11: Updated function signature to use CommunityContext.The type of the bot parameter has been correctly updated from MainContext to CommunityContext, maintaining type safety while modernizing the codebase.
jobs/delete_published_orders.ts (3)
4-7: Properly converted require to import statements and added necessary imports.Good job converting the CommonJS require syntax to ES module import syntax for deleteOrderFromChannel and adding the necessary imports for CommunityContext and IOrder.
9-9: Updated function signature to use CommunityContext.The type of the bot parameter has been correctly updated from MainContext to CommunityContext, maintaining type safety while modernizing the codebase.
25-25: Improved type safety with explicit type assertion.Adding the explicit type assertion to orderCloned improves type safety and makes the code more robust.
bot/middleware/user.ts (1)
1-5: Appropriate context type transition.The middleware functions have been correctly updated to use
CommunityContextinstead ofMainContext, which is consistent with the PR objective to modernize the codebase.jobs/pending_payments.ts (3)
7-10: Successful transition to ES6 import syntax.The code has been successfully updated to use ES6 import syntax instead of CommonJS require statements, which is consistent with the PR objective.
12-12: Function signature updated correctly.The function signature has been properly updated to use
Telegraf<CommunityContext>instead ofTelegraf<MainContext>.
122-122: Function signature updated correctly.The function signature has been properly updated to use
Telegraf<CommunityContext>instead ofTelegraf<MainContext>.bot/start.ts (7)
6-32: Successful transition to ES6 import syntax.The code has been successfully updated to use ES6 import syntax instead of CommonJS require statements, which is consistent with the PR objective.
157-164: Bot initialization properly updated to use CommunityContext.The
initializefunction has been correctly updated to useCommunityContextinstead ofMainContext, ensuring type consistency.
396-418: Approve context type update.The handler has been correctly updated to use
CommunityContextinstead ofMainContext.
421-465: Approve context type update and ES6 imports usage in ordersActions.
- The handler correctly uses
CommunityContext.- The code now uses
ordersActionsimported via ES6 import syntax.
467-529: Approve context type update.The handler has been correctly updated to use
CommunityContextinstead ofMainContext.
764-825: Approve consistent context type updates.All action handlers have been correctly updated to use
CommunityContextinstead ofMainContext.
938-950: Approve function signature update.The
startfunction signature has been correctly updated to useCommunityContextinstead ofMainContext.bot/commands.ts (13)
10-12: Clean transition to ES6 module syntaxGood job converting the CommonJS
requireto ES6importsyntax for the OrderEvents module and updating the imports for utility functions. This aligns with modern JavaScript practices and enhances code maintainability.
19-20: Proper type imports for context objectsGood job importing both
HasTelegramandMainContextfrom./startalong withCommunityContextfrom the community module. This facilitates the transition to the new context types being used throughout the codebase.
23-23: Function signature update for bot parameterYou've correctly updated the
waitPaymentfunction to useHasTelegramfor the bot parameter instead ofMainContext, which aligns with the PR objective of modernizing the codebase and improving type safety.
33-33: Good use of removeLightningPrefix utilityCorrectly using the newly imported
removeLightningPrefixutility function to sanitize the buyer invoice, which provides better encapsulation of this functionality.
90-90: Enhanced function signature with default parameterThe function signature has been updated to use
CommunityContextinstead ofMainContextfor the context parameter, andHasTelegramfor the bot parameter. Additionally, a default value ofnullhas been added for theorderparameter, making the function more flexible.
179-179: Proper update of context typesThe
rateUserfunction now correctly usesCommunityContextfor the context parameter andHasTelegramfor the bot parameter, which is consistent with the other function signature updates in this file.
242-242: Updated function signature with optional parameterThe
cancelAddInvoicefunction has been updated to useCommunityContextfor the context parameter and to set a default value ofnullfor theorderparameter, which improves function flexibility.
359-359: Consistent parameter type updatesThe
showHoldInvoicefunction signature has been updated to useCommunityContextfor the context parameter andHasTelegramfor the bot parameter, which is consistent with the pattern applied to other functions in this file.
429-429: Updated function signature with optional parameterThe
cancelShowHoldInvoicefunction has been updated to useCommunityContextfor the context parameter and to set a default value ofnullfor theorderparameter, consistent with similar functions in the file.
552-552: Consistent context type updatesThe
addInvoicePHIfunction signature has been updated to useCommunityContextfor the context parameter andHasTelegramfor the bot parameter, maintaining consistency with other function signatures in this file.
576-576: Function signature enhancement with optional parameterThe
cancelOrderfunction has been updated to useCommunityContextfor the context parameter and to set a default value ofnullfor theuserparameter, which improves function flexibility and maintains consistency with similar function signatures.
702-702:✅ Verification successful
Note: Different context type used
The
fiatSentfunction usesMainContextinstead ofCommunityContextwhich is different from most other functions in this file. Verify if this is intentional or if it should be updated to useCommunityContextfor consistency.
🏁 Script executed:
#!/bin/bash # Check if other functions in the file are using MainContext or if this is an oversight # Search for all function signature declarations in the file that include MainContext rg -A 1 "async.*MainContext" bot/commands.ts # Check if fiatSent is called from anywhere that passes a specific context type rg "fiatSent\(" --include=*.tsLength of output: 893
Final Decision: Consistent Context Type Usage in
fiatSentAfter verifying the context types used in
bot/commands.ts, we found that other functions (e.g.,waitPaymentandrelease) also useMainContext. This confirms that thefiatSentfunction’s use ofMainContextis intentional and consistent with the rest of the file. No changes are required.
738-738:❓ Verification inconclusive
Same context type inconsistency
The
releasefunction also usesMainContextinstead ofCommunityContext. This appears to be consistent with thefiatSentfunction but inconsistent with most other functions in this file. Verify if this distinction is intentional based on how these functions are used.
🏁 Script executed:
#!/bin/bash # Check if release is called from anywhere that specifically requires MainContext # Search for all calls to the release function rg "release\(" --include=*.tsLength of output: 475
Verify the Context Consistency in Function Usage
The
releasefunction usesMainContext(consistent withfiatSent) while most other functions in this file useCommunityContext. Before approving this divergence, please manually verify that usingMainContexthere is intentional and fits the function’s invocation sites. Notably, our earlier search attempt encountered a flag error; re-running the search with the corrected command (above) should help confirm if any call sites explicitly requireMainContext.
🏁 Script executed:
#!/bin/bash # Re-run search for all invocations of the release function in .ts files using the correct flag rg "release\(" -g "*.ts"Length of output: 259
Review Action: Confirm Context Type Usage for
releaseThe search shows that the
releasefunction is only called inbot/start.tswhere the passedctxis used consistently with MainContext. This mirrors the approach used in thefiatSentfunction. However, since most functions in the file useCommunityContext, please double-check whether usingMainContexthere is intentional and correctly reflects the intended usages.bot/messages.ts (25)
3-15: Clean transition to ES6 module syntaxGood job using ES6 destructuring syntax for imports from '../util'. This makes the code more maintainable and aligns with modern JavaScript practices.
16-16: Improved import syntax for OrderEventsSuccessfully converted the CommonJS
requireto ES6import * as OrderEvents from './modules/events/orders';, which is consistent with the changes in other files.
28-28: Added CommunityContext importCorrectly added import for
CommunityContextwhich is needed for the updated function signatures throughout the file.
70-74: Enhanced null checking logicThe code now properly handles the case where
currencyObjectorcurrencyObject.symbol_nativemight be undefined, using the logical AND operator with the nullish check. This improves code robustness.
206-206: Updated context type in function signatureThe
expiredInvoiceOnPendingMessagefunction now usesTelegraf<CommunityContext>instead ofMainContextfor the bot parameter, which aligns with the PR objective.
309-309: Consistent function signature updateThe
invalidDataMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, which is consistent with other function signature updates.
317-317: Simplified function signatureThe
genericErrorMessagefunction signature has been updated to useHasTelegramfor the bot parameter and no longer requires a context parameter, which simplifies the function usage.
368-371: Improved null checking logicSimilar to earlier changes, this code properly handles the case where
currencyObjectorcurrencyObject.symbol_nativemight be undefined, enhancing code robustness.
516-516: Updated bot parameter typeThe
takeSellWaitingSellerToPayMessagefunction now correctly usesHasTelegramfor the bot parameter instead ofMainContext, which is consistent with other function signature updates.
551-551: Updated context type in function signatureThe
rateUserMessagefunction now usesTelegraf<CommunityContext>for the bot parameter, aligned with the PR objectives and consistent with other function signature updates.
608-609: Improved error handlingAdded explicit check for
undefinedchannel and throw an appropriate error message, which provides better error diagnostics.
645-646: Consistent error handlingSimilar to the previous check, added explicit check for
undefinedchannel and throw an appropriate error message, maintaining consistency in error handling.
681-682: Enhanced error handlingAdded explicit check for
undefinedmessage and throw an appropriate error message, providing better error diagnostics.
855-855: Updated bot parameter typeThe
addInvoiceMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, consistent with other function signature updates.
877-877: Updated bot parameter typeThe
sendBuyerInfo2SellerMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, aligned with the PR objectives.
1023-1023: Function signature update for context typeThe
successCancelOrderByAdminMessagefunction now usesTelegraf<CommunityContext>for the bot parameter, consistent with the pattern applied to other functions.
1042-1042: Updated bot parameter typeThe
successCompleteOrderByAdminMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, aligned with the PR objectives.
1207-1207: Updated bot parameter typeThe
priceApiFailedMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, consistent with other function signature updates.
1364-1364: Updated bot parameter typeThe
expiredOrderMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, consistent with other function signature updates.
1381-1381: Updated bot parameter typeThe
toBuyerExpiredOrderMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, aligned with the PR objectives.
1392-1392: Updated bot parameter typeThe
toSellerExpiredOrderMessagefunction now usesHasTelegramfor the bot parameter instead ofMainContext, maintaining consistency with other function signature updates.
1485-1487: Updated context type in function signatureThe
toAdminChannelPendingPaymentSuccessMessagefunction now usesTelegraf<CommunityContext>for the bot parameter, which is aligned with the pattern applied to other functions in this file.
1509-1511: Consistent context type updatesThe
toBuyerPendingPaymentSuccessMessagefunction now usesTelegraf<CommunityContext>for the bot parameter, maintaining consistency with similar functions.
1530-1530: Updated context type in function signatureThe
toBuyerPendingPaymentFailedMessagefunction now usesTelegraf<CommunityContext>for the bot parameter, which is consistent with the pattern applied to other functions.
1556-1558: Consistent context type updatesThe
toAdminChannelPendingPaymentFailedMessagefunction now usesTelegraf<CommunityContext>for the bot parameter, maintaining consistency with similar functions in this file.
| bot.command('setlang', userMiddleware, ctx => commands.setlang(ctx as unknown as MainContext)); | ||
| bot.action(/^setLanguage_([a-z]{2})$/, userMiddleware, ctx => actions.setLanguage(ctx as unknown as MainContext)); |
There was a problem hiding this comment.
Risky type assertion may lead to compatibility issues.
The code is using a potentially dangerous type assertion (ctx as unknown as MainContext) while the bot is now configured with CommunityContext. This inconsistency could lead to runtime errors if these context types aren't compatible.
Consider refactoring these handlers to work with CommunityContext instead of using type assertions:
- bot.command('setlang', userMiddleware, ctx => commands.setlang(ctx as unknown as MainContext));
- bot.action(/^setLanguage_([a-z]{2})$/, userMiddleware, ctx => actions.setLanguage(ctx as unknown as MainContext));
+ bot.command('setlang', userMiddleware, commands.setlang);
+ bot.action(/^setLanguage_([a-z]{2})$/, userMiddleware, actions.setLanguage);Then update the command and action implementations to accept CommunityContext instead of MainContext.
Alternatively, if you need to maintain backwards compatibility temporarily:
- bot.command('setlang', userMiddleware, ctx => commands.setlang(ctx as unknown as MainContext));
- bot.action(/^setLanguage_([a-z]{2})$/, userMiddleware, ctx => actions.setLanguage(ctx as unknown as MainContext));
+ // TODO: Update commands.setlang and actions.setLanguage to use CommunityContext
+ bot.command('setlang', userMiddleware, ctx => commands.setlang(ctx));
+ bot.action(/^setLanguage_([a-z]{2})$/, userMiddleware, ctx => actions.setLanguage(ctx));📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| bot.command('setlang', userMiddleware, ctx => commands.setlang(ctx as unknown as MainContext)); | |
| bot.action(/^setLanguage_([a-z]{2})$/, userMiddleware, ctx => actions.setLanguage(ctx as unknown as MainContext)); | |
| bot.command('setlang', userMiddleware, commands.setlang); | |
| bot.action(/^setLanguage_([a-z]{2})$/, userMiddleware, actions.setLanguage); |
webwarrior-ws
changed the title
Converted requires to imports where applicable and fixed
type errors resulting from it.
Also removed
@ts-checkannotations. They are used to typecheck .js files, but make no sense in .ts files as they are already type-checked.Summary by CodeRabbit
Refactor
Chore