v2.0.0

BREAKING CHANGES

• fix: strict parsing (7df3246)
  This is a BREAKING CHANGE in terms of the previous strict parsing behavior. The parsing in EmailAddress::new parses the local_part and domain together as a single address as opposed the previous behavior of parsing those separately. This may lead to mismatch with the previous behavior.

Features

• add FromStr method for EmailAddress (8c27262)

Others

• Make wasm-bindgen dependency optional. (96ccb04)

v1.0.0

Features

• Enabled parsing local part, and domain on instantiation (92b2af9). EmailAddress::new (in Rust) or new EmailAddress(...) (in JS) throws error if either local part or domain is invalid.
• Added EmailAddress::is_valid (in Rust), and EmailAddress.isValid() (in JS) to simply validates a given string. This parses like the parse method, but does not instantiates an EmailAddress object, and return true/false instead (3988d98).
• Adding unicode support RFC 6532 (5d1f60e).

Breaking Changes

• The methods localPart(), and domain() exposed to JS, has been converted to ES6 getters. This means email.localPart() or email.domain() can simply be converted to email.localPart and email.domain respectively.
• In JS, the static method EmailAddress.new has been converted to a constructor. Use simply new EmailAddress(...) to instantiate EmailAddress.
• The signature of parse and new has been changed. Instead of an optional boolean as the lat parameter, they now expect an optional ParsingOptions instance.
• The constructor function (new) not returns Result<EmailAddress, String> in Rust instead of Option<EmailAddress>. Semantically, this makes more sense. In JS side, the core new function has been wrapped with a constructor function that panics (throws error in JS). The later function is not meant to be used from Rust, and strictly for JS users.

v0.3.0-rc2

Initial release of an RFC 5233 compliant email parser.