Public release of version 5.0.0

Today we announce the general availability of Maily version 5.0.0. A big change for you as a user! But don't worry, Maily still does exactly what you can expect from it. As a major update, this does with some breaking changes.

Major differences

• Switch to ES6 default export system over module.exports
• New versioning scheme
• Update of React to 16.8
• Improved testability using validation
• Optional minimization of generated HTML

We'll list each change separately so you can assess impact on your usage.

Switch to ES6 default export

Back in the days, Maily was a bit stuck in the time where one would use module.exports = x to export a module. Over the last few weeks the code base has been improved and modernized. As such, we now export our dependency using the ES6 export default system.

If you were importing Maily using const maily = require('maily') you might want to switch towards an ES6 import, or add a .default behind the require option. The former is preferable to use.

This is a breaking change, though not one which should cause serious problems.

New versioning scheme

In #16 (plus internally) we'd discussed the version scheme we used for Maily in the past. Under that previous scheme, Maily would stay exactly on par with our major dependency MJML. This caused problems when moving to either newer React version, where we would update these ad-hoc, and not adhere to semantic versioning. It also posed problems to evolve parts of Maily's API apart from MJML updates.

As such, we have now switched to a new system, of which this is the first release. Under this new scheme, we will adhere to the following rules, and Maily will no longer follow MJML.

1. Major updates to MJML or React bump our major version number.
2. Any API breaking change in Maily bumps our major version number.
3. Minor and patch updates of React or MJML update the respective number as well.
4. New features in Maily update the minor version number as long as they do not break a previous contract.

Whenever possible we will add deprecation notices a major version prior to actually breaking previous behaviour.

This change allows you to follow Maily updates easier, and with more confidence.

Update of React to 16.8

Previously Maily was stuck on a relatively old version of React. This did not pose a major problem, as many newer React versions do not benefit the single run generation of Maily. However it caused frontend developers to often work in quite different stacks, which can be time consuming.

As of version 5.0.0, we will keep try to better keep track of React updates. For breaking changes, the major version number will be increased.

Improved testability using validation

While MJML is a great language to use to build better emails, and Maily adds even more syntactic sugar, the process is not always hassle-free. A major pain point was the incorrect usage of MJML native components, often due to unsupported nesting.

In version 5.0.0 we have introduced an options object to pass to Maily. One can set the flag mjmlStrict to true: this will validate your MJML during generation, and output any problems directly into the servers console. We recommend everyone to switch on this flag, as it really aids during developing and debugging. Internally, we saw a reduction in time of 60% required to build a bullet-proof email!

Optional minimization of generated HTML

Emails as generated by MJML may generate a lot of white space, thereby significant increasing the size of your email. As GMail still poses a limit of around 100kb on an HTML email prior to cutting it arbitrarily, minification of this HTML can be your friend.

From version 5.0.0 Maily can do this natively. You can pass an object minificationOptions containing the htmlMinificationOptions (following html-minifier). We use the following minification options, which seems to work really well while cutting some HTML emails in half!

{
	collapseInlineTagWhitespace: true, // Collapse spaces in tags
	collapseWhitespace: true, // Remove redundant whitespace
	conservativeCollapse: true, // Be careful when collapsing
	maxLineLength: 80, // Limit to a length clients can understand
	minifyCSS: false, // Dont touch CSS
	minifyURLs: false, // Emails cannot be relative
	// THIS NEEDS TO BE SET TO FALSE
	// Outlook is sensitive to spaces in conditional comments. So if you have <element attribute[space]attribute>
	// things work, but if anything happens to become <element attribute[enter]attribute> the damn thing just gives
	// up. As a result Outlook gives up rendering the entire document, and just shows the background color, and nothing
	// else.
	// Additionally Outlook gives up if some conditional comments change casing or with VML
	// SO WE ARE NOT PROCESSING THESE COMMENTS
	processConditionalComments: false, // NO, you do not need to change this
	// READ THE COMMENT ABOVE BEFORE TRYING TO CHANGE ANYTHING
	removeComments: false, // Dont remove comments, in email they contain valuable code
	removeEmptyAttributes: true,
	removeEmptyElements: true,
}

Internal changes

• We've switched to yarn over npm
• Improved testing of MJML components to guarantee no unintended rendering changes happen
• Improved linting to make commits less likely to conflict
• Added automated testing using Travis
• Re-enabled code climate integration