Announcing MJML v2.0
What we learnt so far
A few months ago, we launched MJML, our responsive email markup language, to answer one of the biggest issues in the email industry: the non homogeneous and poor support of HTML in email clients.
From this first release we experienced what it takes to maintain a popular repository on Github. We had a lot of issues and interesting feature requests that drove most updates.
The interest from the community confirmed that coding an email is still a real pain for developers these days and that we needed to enhance MJML to keep pace with and feed our community excitement.
What needed to be improved
MJML was a success. However, we quickly found out that the community wanted the project to go far beyond our expectations.
Out of more than a hundred opened issues on Github, a lot of them were about importing components, styling, rendering on different email clients and so much more. We had to make a lot of additions and deal with large pull requests in a trending repository.
How we did it
The new monorepo design answers just that. Leveraging smaller components of the projects, pull requests are easier to document, test, and merge. MJML is now split between mjml-core, mjml-text, mjml-cli and many more packages that can be improved and fixed on their own without republishing the entire repository.
The documentation can now be generated by concatenating every packages’ README.md, which will allow the pull request authors to explain their change during the process and see the new documentation updated with their code and description, and later, to open source the documentation.
The monorepo design also allows us to keep all the user issues in the same place, organized by tags, even though they are dealing with different packages.
One of the top 5 questions we encountered while maintaining MJML was the following: How do you import an external component? Many approaches were considered. An mj-import tag, a mandatory .js file, an mjml-project folder, or, the one we came with, a .mjmlconfig file that will contain your packages declaration.
This approach looks like the package.json file from javascript projects. It will enable us to extend MJML with many more functionalities/features in the future, and group all the configuration needed for a project in one file.
In addition to that, we added a root tag, `mjml` that can contain the mj-body tag and later, an eventual mj-style/mj-attributes/mj-font if needed, like the `html` tag in HTML. Of course this new syntax is backward compatible with your previous templates, but it is recommended to update your existing templates as soon as possible:
Note that the rendered body will now be generated by the mj-container tag. Mj-body will now be a structure-focused tag and will not render anything in the final email.
With this new structure, it gives us the flexibility to introduce new configuration tags on top of MJML templates to manipulate the email before and after the rendering, and to render single components without a body.
Finally, MJML 2.0 leverages React 15, which strengthens the css typing within the components creation.
We are sure you are going to love MJML 2.0, so check it out!
