Skip to content
This repository has been archived by the owner on Feb 6, 2022. It is now read-only.

Releases: inventid/maily

Public release of version 5.1.0

19 Apr 12:53
33f3430
Compare
Choose a tag to compare

This version fixes an annoyance in the generated text emails, where the resulting TXT would be url-encoded. This caused certain characters, such as "', to be escaped.

From this version onwards, they are properly shown in the HTML (encoded) en txt (unencoded). Tests have been added so this is not the defined behaviour

Public release of version 5.0.0

14 Mar 20:26
7ab9cc8
Compare
Choose a tag to compare

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

Public release of Maily 4.1.2

20 Aug 09:19
2cf48e7
Compare
Choose a tag to compare

This version of Maily will update the used version of mjml to version 4.1.2.

Over our previous versions, this has a lot of improvements!

Improved MJML support

Rendering components using React could be a bit hard, as nesting mj-section could produce weird results. Additionally it was hard to figure out whether there were any validation conflicts.

For this we have introduced the mjStrict parameter in the options object. Setting this to true will output any mjml validation errors, which wil be a huge assist in solving errors.

License

The license of maily was unclear. At inventid we strive to use MIT licenses whenever we can. We therefore made this clearer by adding this to the repository itself

Reduced package size

A number of unneeded files are no longer published to npm, causing a smaller bundle size.

Links to blogs in README

Previously we have blogged on how to use Maily, and how to setup your personal maily environment. We recommend you read these blogs which you can find at:

Release 1.1.2

01 Jul 09:50
Compare
Choose a tag to compare

This is a small maintenance release. It increases the maximum size of bodies sent to maily to 1MB by default (this used to be 100kb).

For users sending smaller payloads this does not change anything. For users which are interested in sending larger payload this fix might be worthwhile to deploy.