Multi environment support

[hassancodess]

This PR includes the following updates:

• Added development and production scripts to package.json.
• Updated README with instructions for .env.development and .env.production.
• Added .env.development and .env.production to .gitignore.

Summary by Sourcery

Add support for multiple environments by introducing separate development and production configurations. Enhance environment variable management with improved error handling and update documentation to guide users in setting up environment files. Refactor import paths in the upload controller to reflect the new module structure.

New Features:

• Introduce multi-environment support by adding development and production environment configurations.

Enhancements:

• Switch from dotenv to dotenvx for environment variable management and improve error handling with pretty-printed error messages for environment variable validation.
• Refactor import paths in the upload controller to align with the new module structure.

Documentation:

• Update README to include instructions for setting up .env.development and .env.production files.

Chores:

• Add .env.development and .env.production to .gitignore to prevent them from being tracked in version control.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request implements multi-environment support by updating the configuration service, adding development and production scripts, and improving error handling for environment variables. It also includes updates to the README and some minor refactoring.

File-Level Changes

Change	Details	Files
Improved environment variable handling and configuration	Replaced dotenv with @dotenvx/dotenvx for environment variable loading Implemented safeParse instead of parse for more robust error handling Added a prettyPrintErrors function to format and display configuration errors Removed optional DATABASE_URL from the config schema Added process exit on configuration errors	src/config/config.service.ts
Updated README with multi-environment instructions	Added instructions for creating .env.development and .env.production files Removed mention of single .env file	README.md
Minor refactoring in upload controller	Updated import paths for user-related modules	src/upload/upload.controller.ts

---

Tips

• Trigger a new Sourcery review by commenting @sourcery-ai review on the pull request.
• Continue your discussion with Sourcery by replying directly to review comments.
• You can change your review settings at any time by accessing your dashboard:
  • Enable or disable the Sourcery-generated pull request summary or reviewer's guide;
  • Change the review language;
• You can always contact us if you have any questions or feedback.

[sourcery-ai]

Hey @hassancodess - I've reviewed your changes and they look great!

Here's what I looked at during the review

• 🟡 General issues: 1 issue found
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟡 Documentation: 1 issue found

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[sourcery-ai]

suggestion: Consider making prettyPrintErrors more flexible

Instead of logging directly to the console, consider having the function return a formatted string. This would make it more reusable in different contexts, allowing the caller to decide how to handle the output.

const prettyPrintErrors = (errObj: ZodError): string => {
  let output = '';
  const formattedError = errObj.format();
  Object.entries(formattedError).forEach(([key, value]) => {
    if (value && '_errors' in value) {
      output += `${key}: ${value._errors.join(', ')}\n`;
    }
  });
  return output.trim();
};

[sourcery-ai]

suggestion (documentation): Consider explaining the reason for separate development and production environment files.

While separating environments is a good practice, a brief explanation of why you're using two files now might help users understand the change better.

Suggested change

	- Create a `.env` file in the root directory.
	- Use the provided `.env.sample` as a template to enter all the required environment variables.
	- Create `.env.development` and `.env.production` files in the root directory.
	- Use the provided `.env.sample` as a template to set up the environment variables in these files.
	## What's Included
	- Create `.env.development` and `.env.production` files in the root directory:
	- `.env.development` for local development settings
	- `.env.production` for production environment settings
	- This separation allows for different configurations based on the environment
	- Use the provided `.env.sample` as a template to set up the environment variables in these files