GoMail is a powerful library for sending emails via multiple providers, including SMTP, Gmail API, Microsoft Graph API, SendGrid, AWS SES, Mailgun, Mandrill, Postmark, and SparkPost. Supporting attachments, plain text, and HTML content, it simplifies email integration for developers with easy setup and robust functionalities.
Is your feature request related to a problem? Please describe.
Currently, the gomail library has common components (such as EmailMessage, Attachment, and utility functions) located directly in the root directory. This can make the project harder to navigate and maintain, especially as it grows. The lack of organization can also make it difficult for new contributors to understand the project structure quickly.
Describe the solution you'd like
I propose refactoring the common components into a dedicated common directory to improve project organization. To maintain backward compatibility, we will create alias files in the root directory that import and re-export these components from the common directory. This ensures that existing code importing from the root will still function correctly while new code can use the more organized structure.
Describe alternatives you've considered
Keep the current structure: This would avoid any immediate changes but would not address the growing complexity and maintainability issues.
Move components without aliases: This would simplify the project structure but would break backward compatibility for existing users who import from the root directory.
Additional context
This change will help in maintaining a cleaner project structure, making it easier for contributors to navigate and understand the codebase. It also sets a foundation for better scalability and maintainability as the project evolves.
Is your feature request related to a problem? Please describe.
Currently, the
gomaillibrary has common components (such asEmailMessage,Attachment, and utility functions) located directly in the root directory. This can make the project harder to navigate and maintain, especially as it grows. The lack of organization can also make it difficult for new contributors to understand the project structure quickly.Describe the solution you'd like
I propose refactoring the common components into a dedicated
commondirectory to improve project organization. To maintain backward compatibility, we will create alias files in the root directory that import and re-export these components from thecommondirectory. This ensures that existing code importing from the root will still function correctly while new code can use the more organized structure.Describe alternatives you've considered
Additional context
This change will help in maintaining a cleaner project structure, making it easier for contributors to navigate and understand the codebase. It also sets a foundation for better scalability and maintainability as the project evolves.