email-validate-hs
email-validate-hs copied to clipboard
Major version changes (v3)
Ideas for v3:
- [x] Input type should be Text, not ByteString (see #9)
- [x] Test suite will be inherited from Dominic Sayer's
isemail
, and won't be inlined in the code. - [x] The basic
EmailAddress
should not provide individual access tolocalPart
/domainPart
, but instead be anewtype
aroundText
. This will facilitate loading/storing from unvalidated stores in a simpler fashion than is currently possible (e.g. at the moment you can useunsafeEmailAddress
but it takes the two parts separately, not a single email address string). - [x] Lift
ParseOptions
to type level, per this comment. - [x] The default parsing mode will change to something saner that excludes "obsolete" syntaxes (these can be accessed using the "Detailed" module).
- [ ] Support internationalized emails.
- [x] In local parts
- [ ] Add tests for each bit (atext, ctext, etc – ignore dtext since we'll do proper handling)
- [ ] In domains (this probably requires an IDNA2008 implementation)
- [x] In local parts
- [ ] For those who want full analysis, there will be a separate "Detailed" module which can break apart an email address. (Or, just provide functions to break down the
EmailAddress
type...)- [ ] This module will provide
DomainPart = HostName | IP
. TODO: what modules to depend on for IP address types? There are currently ip, network-ip, others? Do any of them expose parsers fromText
? Resolution: I choseip
for now, since it provides AttoparsecText
parsers. To pass tests I need to close these issues:- [x] Support 'mixed' IPv6 representations
- [x] PR submitted – released in 1.3.0
- [x] Support for converting IPv6 to Text
- [x] PR submitted
- [x] Support 'mixed' IPv6 representations
- [ ] This module will provide
- [ ] Error messages should be improved, and this checked by tests.
- [ ] Consider exposing an FFI interface for other languages to use.
- [ ] Consider improved equality (see #36) this should fall out of better domain parsing
- [ ] Consider switching to Megaparsec, for better error messages?
- [ ] Consider which instances to upstream from https://github.com/cdepillabout/emailaddress (as pointed out by @bitemyapp)
- [x] NFData (per #25)
- [x] Binary (per #25)
- [ ] PathPiece (per #20)
- [ ] Aeson instances (from
emailaddress
)
8c6e0c7d906 adds the isemail
test-suite.
Another thing to think about: I should be testing the canonicalized versions of email addresses to ensure the normal form is as expected. (The isemail
suite does not do this.)
Idea: use DataKinds
for the options type that controls what to allow in the email address.
This way we have type EmailAddress = EmailAddress' SaneParseOptions
and you can't accidentally mix email addresses parsed with different levels of flexibility.
Also: add a RestrictedEmailAddress
for "Emails as they supported by most major providers".
Edit: didn't use DataKinds because that forces it onto the consumer. Instead we have a typeclass ParseOptions
which supplies the configuration. This provides the extra safety without any extra burden on consumers.
@Porges Don't you know my IPv6Addr package? It should give all you need about IPv6 addresses. If not, feel free to contact me.
@MichelBoucey I didn't come across it when I was looking. It looks like it could be useful. I'll stick with ip
for now until I get everything working and then have a better look.
One thing that might be required is: in order to pass the test-suite, in some situations I have to be able to parse IPv4-only addresses and not accept IPv6 ones. I'm not sure if this is possible with your current API (except if I parse and then check the result to see if it is IPv4-compatible).