Hi! Could you please assign this issue to me? I'd love to work on it.

Hi @Mrinank-Bhowmick, thanks a lot for taking the initiative! I’ve assigned the ticket to you and updated the issue with more detailed guidelines. Welcome and happy coding!

@Mrinank-Bhowmick Just a couple of suggestions from an offline sync-up with @natanasow:

1. In the ConfigService.get() function, we could use the variable type from globalConfig.ts:

   public static get(name: string): string | number | boolean | null | undefined {
       const varType = GlobalConfig.ENTRIES[name].type;
       return this.getInstance().envs[name] as varType;
   }

   Of course, varType would need to be cast to the correct type first, but this is one approach to consider.

2. Another suggestion is to create a new enum called ConfigName (or similar) containing all config names, like:

   enum ConfigName {
       BATCH_REQUESTS_ENABLED = "BATCH_REQUESTS_ENABLED",
       ...
   }

   Then, for ENTRIES in GlobalConfig, we can use Record<ConfigName, ConfigProperty> instead of <string, ConfigProperty>. This would also help the get() function, allowing it to take name: ConfigName instead of string, improving type safety and reducing the risk of passing in unintended strings.

Please let me know if you need any support getting started on the issue or during development. We’re happy to assist!

After reviewing the requirements for this issue, I've realized I'm not able to take it on at this time. I'm unassigning myself to allow others to work on it.

Thanks @Mrinank-Bhowmick!

@quiet-node I will like to work on this issue.

Hi @quiet-node and @Nana-EC,

I’d like to request permission to work on [Issue #3142](#3142), which focuses on fixing TypeScript warnings and errors related to type mismatches in ConfigService.get(<envName>).

I’ve reviewed the issue details and understand that it involves identifying and resolving type inconsistencies in the test specs by refactoring test cases for type alignment.

Please let me know if I can take this on or if there are any specific guidelines you’d like me to follow while working on this.

Looking forward to your feedback!

Best regards,
Ibrahim Bello

Hi @belloibrahv

I apologize for the delayed response; I completely overlooked this. Really appreciate your initiative! I've assigned you to the ticket.

I believe you're on the right track. Here’s a helpful reference for the solution: #3142 (comment)

OK, @quiet-node thanks for assigning the issue to me, currently looking into it 🚀

Hi @quiet-node @natanasow, I noticed the 'NON_EXISTING_VAR' does not exist in the GlobalConfig.ENTRIES as part of the envName listed. I suggest adding it to ensure type safety when retrieving configuration values. Or do what you think about it.

Hi @quiet-node @natanasow,

I hope this message finds you well. I’m currently working on the issue #3142 (Fix all TypeScript warnings and errors generated by type mismatching on the ConfigService.get(<envName>) method in test specs).

While committing and signing off my changes, I encountered several linter errors during the build-and-test process. These errors seem unrelated to the code changes I’ve made, as they primarily point to existing issues in the repository. Below are a few examples of the errors:

• Error: 'accounts' is never reassigned. Use 'const' instead (prefer-const)
• Warning: Require statement not part of import statement (@typescript-eslint/no-var-requires)
• Warning: 'data' is defined but never used (@typescript-eslint/no-unused-vars)

These issues are originating from files such as:

• /tests/integration/server.spec.ts
• /tests/acceptance/getTransactionByHash.spec.ts
• /tests/acceptance/sendRawTransaction.spec.ts, and others.

I’ve ensured that my changes align with the task requirements, and the issues above were not introduced by my code.

Could you kindly guide me on how to proceed? Should I address these linter issues as part of this task, or would you recommend an alternate approach to commit and push my changes without being blocked by these errors?

Thank you for your support!

Best regards

@quiet-node @natanasow @Nana-EC Please kindly help address the issues and questions on the task.

Thank you for the update, @belloibrahv, and I apologize for my late response! Looking into these updates and will share my thoughts on them soon.

Hi @quiet-node @natanasow, I noticed the 'NON_EXISTING_VAR' does not exist in the GlobalConfig.ENTRIES as part of the envName listed. I suggest adding it to ensure type safety when retrieving configuration values. Or do what you think about it.

This is a good idea! @natanasow what do you think?

Hi @quiet-node @natanasow,

I hope this message finds you well. I’m currently working on the issue #3142 (Fix all TypeScript warnings and errors generated by type mismatching on the ConfigService.get(<envName>) method in test specs).

While committing and signing off my changes, I encountered several linter errors during the build-and-test process. These errors seem unrelated to the code changes I’ve made, as they primarily point to existing issues in the repository. Below are a few examples of the errors:

• Error: 'accounts' is never reassigned. Use 'const' instead (prefer-const)
• Warning: Require statement not part of import statement (@typescript-eslint/no-var-requires)
• Warning: 'data' is defined but never used (@typescript-eslint/no-unused-vars)

These issues are originating from files such as:

• /tests/integration/server.spec.ts
• /tests/acceptance/getTransactionByHash.spec.ts
• /tests/acceptance/sendRawTransaction.spec.ts, and others.

I’ve ensured that my changes align with the task requirements, and the issues above were not introduced by my code.

Could you kindly guide me on how to proceed? Should I address these linter issues as part of this task, or would you recommend an alternate approach to commit and push my changes without being blocked by these errors?

Thank you for your support!

Best regards

Hmm, that's strange! Were you able to rebase the changes? Did the linting errors persist after the rebase?

Our goal is to keep PRs focused and address only the reported issues for clarity. If you believe these errors were not introduced by your code, please open a new ticket in the repository to report them for easier tracking. The team will review the ticket and determine how to address them.

Thanks for the great work and effort as always!

Hi @quiet-node @natanasow, I noticed the 'NON_EXISTING_VAR' does not exist in the GlobalConfig.ENTRIES as part of the envName listed. I suggest adding it to ensure type safety when retrieving configuration values. Or do what you think about it.

This is a good idea! @natanasow what do you think?

@belloibrahv In that test, we want to ensure if the var is missing, the config service will not brick or throw an error. If we add the NON_EXISTING_VAR to the config array, we will change the initial test goal.

Let's create a new ticket for the linter errors and not commit several issues to a single PR/branch.

Thank you for the great contribution, looking forward to the PR review 🚀 .

@Nana-EC @ebadiere @quiet-node I've submitted a PR addressing issue #3142 to resolve type warnings for ConfigService.get(). It ensures type consistency across test cases by refining type usage and adding/removing the necessary casting. Let me know if further changes are needed. Here's a in the PR #3350 Thank you for reviewing!