chore(format): use eslint as the formatting tool

[Red-Asuka]

This pull request includes several updates to the apps/cli package, focusing on code refactoring, configuration changes, and dependency updates. The most important changes include refactoring functions to use the function keyword, updating import paths, and modifying configuration files to improve code formatting and linting.

Code Refactoring:

• Refactored various functions in apps/cli/src/lib/conn.ts, apps/cli/src/lib/ls.ts, and apps/cli/src/lib/pub.ts to use the function keyword instead of arrow functions for better readability and consistency. [1] [2] [3]
• Updated import paths to use node: prefix for core modules in apps/cli/src/lib/ls.ts and added type imports for better type checking and performance. [1] [2]

Configuration Changes:

• Removed .prettierrc.json file, indicating a switch to using ESLint for formatting.
• Updated .vscode/settings.json to disable Prettier, enable ESLint for various languages, and customize ESLint rules to silence stylistic warnings while still auto-fixing them.

Dependency Updates:

• Added @mqttx/tsconfig and @types/mqttx as workspace dependencies in apps/cli/package.json.

Other Changes:

• Reordered and restructured import statements in apps/cli/src/index.ts and apps/cli/src/lib/pub.ts for better organization and readability. [1] [2]

These changes aim to improve the codebase's maintainability, readability, and consistency across the project.

[ysfscream]

I have some thoughts and suggestions for the optimization of ESLint. I don't want overly strict rules to exist. Of course, excellent lint will make code more readable and understandable and enhance development efficiency.

However, if there are too many rules or destructive rules, it will cause many troubles for developers. Therefore, I want to find a balance point in the middle to meet the requirements, but don't overly pursue "perfection".

[Red-Asuka]

I have some thoughts and suggestions for the optimization of ESLint. I don't want overly strict rules to exist. Of course, excellent lint will make code more readable and understandable and enhance development efficiency.

However, if there are too many rules or destructive rules, it will cause many troubles for developers. Therefore, I want to find a balance point in the middle to meet the requirements, but don't overly pursue "perfection".

Certainly, there is much to discuss regarding the optimization of ESLint. I completely agree that finding the right balance in rule-setting is essential. The complexity of ESLint sometimes draws criticism, but importantly, most errors can be automatically fixed upon saving the file. Additionally, adhering to certain recommended practices can indeed enhance the robustness and maintainability of the code. We need to continue discussing and adjusting to ensure the rules are neither too strict nor too lenient, thereby helping developers to efficiently write higher-quality code.