Feedback on my first laravel composer package

Hi everyone!

I just created my first laravel composer package and uploaded it to packagist:

packagist: https://packagist.org/packages/loots-it/laravel-mail-template-channel github: https://github.com/Loots-it/laravel-mail-template-channel

The main reason I build this package is because I want to use Jetstream for my auth scaffolding, but I like to use mailjet templates for my transactional mails instead of the standard laravel mail templates/logic. That's why I created a new ExternalMailTemplateChannel, it's a variant on the standard MailChannel from Laravel. All you have to do to integrate it with the Jetstream scaffolding is change the Jetstream notifications to use the new ExternalMailTemplateChannel class by implementing the toExternalMailTemplate() method and adding the channel in the via() method. Which should be pretty easy. The other channel can then be deleted in the via() method.

To be honest, I still have some refactoring to do, I want to create a 'ExternalTemplateMailMessage' that has to be returned from the notifications to make the toExternalMailTemplate function easier to read and independent of the implemented driver. At the moment the function looks like this for the VerifyEmail notification.

    public function toExternalMailTemplate($notifiable) {

        $variables = [
            "confirmation_link" => $this->verificationUrl($notifiable)
        ];

        return [
            'Subject' => "Verify email address",
            'TemplateID' => 1, //example id
            'Variables' => $variables
        ];
    }

I would love to get some feedback on the package and composer packages in general, because it's my first ever. I know I still have to do some refactoring. But other than that, what is your recommended folder structure in packages? I've seen some packages with the structure contracts/, providers/, services/, facaded/ and it seems nice, but it didn't feel appropriate because this package was so small. What do you think is important for open source packages? And what are the most important things that are missing in mine? Could I have implemented the same functionality using the standard mail channel, in your opinion? I know tests would be a nice addition, but I currently don't know what's the best approach for that. Any suggestions would be appreciated :)

Update: one more thing I also want to refactor is the general from email address and name. At the moment these are stored in the ENV variables, it seems better to be able to config these in a separate config file, just like for the MailChannel.

Sinnbeck

5 years ago

Level 102

Hi @loots

Congrats on the first package. That is a big thing. Looks like a solid start.

I agree that you should add a config file for getting configuration
Take a look at a few other laravel packages for how the folder structure is mostly set up. They often follow a certain structure
Add a README.md with information regarding installation and usage of the package
I would really recommend that you add some tests. It makes the package seem more professional, and it helps catch bugs when you update it or accept PR's

1 like

Loots

5 years ago

Level 4

Hi @sinnbeck

Thanks for your feedback! I did most of the things you suggested. Although I only have one automatic test and another manual test that can run via an artisan command (it's to test the configuration). And of course I still have to add the README.md. I learned a lot by making this package!

I just have one more question. Would you personally consider this package useful? And why/why not? The reason I like to make the templates in mailjet is because it's easily accessible by non technical people. And to me that's important because those people might know a lot more about email design/marketing strategies than I do. Of course it's also possible to import everything into the project after each change but that's a lot of work. And when sending a lot of emails it becomes an overhead to include those html/text messages in every request.

Please or to participate in this conversation.