feat: add prompt for nodejs development

lua/chatgpt_nvim/prompts.lua

@@ -73,6 +73,95 @@ local M = {
 
     Please follow these guidelines to ensure the generated or explained code aligns well with SolidJS best practices for large, maintainable projects.
   ]],
+  ["nodejs-development"] = [[
+    You are helping me develop a large Node.js application. Please keep the following points in mind when generating or explaining code:
+
+    1. **Project & Folder Structure**  
+       - Maintain a clear, top-level directory layout. For example:
+         ```
+         my-node-app/
+         ├── src/
+         │   ├── controllers/
+         │   ├── models/
+         │   ├── routes/
+         │   ├── services/
+         │   ├── utils/
+         │   └── index.js (or app.js)
+         ├── tests/
+         │   └── ...
+         ├── package.json
+         ├── .env (if needed)
+         ├── .eslintrc.js
+         └── ...
+         ```
+       - Keep your application logic separated in folders:
+         - **controllers/** (or handlers) for request handling logic,  
+         - **services/** for core business logic or data processing,  
+         - **models/** for database schemas/entities,  
+         - **routes/** for defining routes/endpoints,  
+         - **utils/** for reusable helper functions.  
+
+    2. **Dependencies & Package Management**  
+       - Use **npm** or **yarn** (pick one and stay consistent) to manage dependencies.  
+       - Keep your `package.json` clean by removing unused dependencies.  
+       - Pin exact versions for critical or sensitive dependencies to ensure reproducible builds.  
+
+    3. **Configuration & Environment Variables**  
+       - Use environment variables to store sensitive or environment-specific information (e.g., database credentials, API keys).  
+       - Consider a config management library (like [dotenv](https://github.com/motdotla/dotenv) or [dotenv-flow](https://github.com/kerimdzhanov/dotenv-flow)) to load environment variables from `.env` files.  
+       - Keep secrets out of version control (e.g., `.env` should be in `.gitignore`).  
+
+    4. **Code Organization & Module Patterns**  
+       - Use **ES Modules** (`import`/`export`) or **CommonJS** (`require`/`module.exports`) consistently across the project.  
+       - Keep each module focused on a single responsibility.  
+       - Use a **service layer** for business logic to avoid bloated controllers.  
+       - Use **async/await** for asynchronous operations, ensuring proper error handling (try/catch blocks or .catch callbacks).  
+
+    5. **Database & Data Persistence**  
+       - Use an ORM/ODM (e.g., [Sequelize](https://sequelize.org/) for SQL, [Mongoose](https://mongoosejs.com/) for MongoDB) or a query builder ([Knex.js](https://knexjs.org/)) to maintain cleaner database interactions.  
+       - Keep database-related logic in separate **models/** or **repositories/**.  
+       - Handle database migrations carefully (e.g., with [db-migrate](https://db-migrate.readthedocs.io/), [Liquibase](https://www.liquibase.org/), or built-in ORM migration tools).  
+
+    6. **Logging & Monitoring**  
+       - Use a structured logging library (e.g., [Winston](https://github.com/winstonjs/winston), [Pino](https://github.com/pinojs/pino)) to capture logs in JSON or another parseable format.  
+       - Ensure logs include enough context (request IDs, timestamps, etc.) to troubleshoot issues.  
+       - Consider external logging and monitoring solutions (e.g., [Datadog](https://www.datadoghq.com/), [New Relic](https://newrelic.com/)) for production environments.  
+
+    7. **Security & Best Practices**  
+       - Sanitize and validate all user inputs (e.g., using libraries like [validator](https://github.com/validatorjs/validator.js)).  
+       - Avoid SQL injection by using parameterized queries or ORM features.  
+       - Implement rate limiting or request throttling to prevent abuse (e.g., [express-rate-limit](https://github.com/nfriedly/express-rate-limit)).  
+       - Ensure **HTTPS** is used in production and secure headers are set (e.g., [helmet](https://github.com/helmetjs/helmet) for Express).  
+       - Keep dependencies updated to patch known vulnerabilities (use `npm audit` or equivalent).  
+
+    8. **Error Handling**  
+       - Use centralized error handling middleware (if using a framework like Express) to catch and process errors consistently.  
+       - Provide clear error messages but avoid leaking sensitive info in production.  
+       - Separate operational errors (e.g., user-related) from programmer errors (e.g., logic bugs) to handle them appropriately.  
+
+    9. **Testing & Quality Assurance**  
+       - Write **unit tests** for individual modules or functions (e.g., using [Jest](https://jestjs.io/), [Mocha](https://mochajs.org/)).  
+       - Use **integration tests** or **end-to-end tests** (e.g., [Supertest](https://github.com/visionmedia/supertest) for API endpoints).  
+       - Aim for high coverage but focus on critical business logic and error cases.  
+       - Automate tests in your CI pipeline.  
+
+    10. **Linting & Formatting**  
+        - Use **ESLint** (with recommended or popular config like [Airbnb](https://www.npmjs.com/package/eslint-config-airbnb)) for consistent code quality.  
+        - Use **Prettier** for code formatting to maintain a standardized style.  
+        - Configure linting and formatting checks in a pre-commit hook or CI (e.g., [Husky](https://typicode.github.io/husky/), [lint-staged](https://github.com/okonet/lint-staged)).  
+
+    11. **Deployment & Environment Management**  
+        - Containerize your app with Docker if possible, specifying a secure and minimal base image.  
+        - Use process managers like [PM2](https://pm2.keymetrics.io/) or systemd for production Node.js processes.  
+        - Maintain separate configuration (or environment variables) for staging, production, etc.  
+
+    12. **Output Format**  
+        - Present any generated source code with clear folder and file placement (e.g., `controllers/`, `services/`).  
+        - When explaining your reasoning, highlight the architectural decisions or patterns used (e.g., “I introduced a service layer to separate business logic from route handling.”).  
+        - If you modify existing files, specify precisely which lines or sections have changed, and why.  
+
+    Please follow these guidelines to ensure the generated or explained code aligns well with Node.js best practices for large, maintainable projects.
+  ]]
   ["go-development"] = [[
     ### Go Development Guidelines