chore: update CHANGELOG and README

Author: ccuilla

CHANGELOG.md

@@ -4,6 +4,18 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/)
 and this project adheres to [Semantic Versioning](http://semver.org/).
 
+## [0.3.0] - 2018-04-03
+### Changed
+- Updated package versions in `devDependencies`
+- Updated `graphql` version dependency to `0.13.1`
+- Added [Prettier](https://prettier.io/) configuration to `package.json`
+- Linted (based on updates to eslint packages) and Prettier-ed all files
+
+### Added
+- PhoneNumber
+- PostalCode
+- `package-lock.json`
+
 ## [0.2.0] - 2018-01-16
 ### Changed
 - Implemented more strict numeric type checking

README.md

@@ -30,6 +30,9 @@ scalar NegativeFloat
 
 scalar EmailAddress
 scalar URL
+
+scalar PhoneNumber
+scalar PostalCode
 ```
 
 In your resolver map, first import them:
@@ -49,6 +52,9 @@ import {
 
   EmailAddress,
   URL,
+
+  PhoneNumber,
+  PostalCode,
 } from '@okgrow/graphql-scalars';
 ```
 
@@ -71,6 +77,9 @@ const myResolverMap = {
   EmailAddress,
   URL,
 
+  PhoneNumber,
+  PostalCode,
+
   Query: {
     // more stuff here
   },
@@ -117,6 +126,9 @@ type Person {
 
   email: EmailAddress
   homePage: URL
+
+  phoneNumber: PhoneNumber
+  homePostalCode: PostalCode
 }
 
 ```
@@ -181,28 +193,45 @@ A field whose value conforms to the standard internet email address format as sp
 A field whose value conforms to the standard URL format as specified in
 [RFC3986](https://www.ietf.org/rfc/rfc3986.txt).
 
+### PhoneNumber
+A field whose value conforms to the standard E.164 format as specified in
+[E.164 specification](https://en.wikipedia.org/wiki/E.164). Basically this is `+17895551234`.
+The very powerful
+[`libphonenumber` library](https://github.com/googlei18n/libphonenumber) is available to take
+_that_ format, parse and display it in whatever display format you want. It can also be used to
+parse user input and _get_ the E.164 format to pass _into_ a schema.
 
-## Future
-We'd like to keep growing this package, within reason, to include the scalar types that are widely
-required when defining GraphQL schemas. We welcome both suggestions and pull requests. A couple of
-ideas we're considering are:
+### PostalCode
+We're going to start with a limited set as suggested [here] (http://www.pixelenvision.com/1708/zip-postal-code-validation-regex-php-code-for-12-countries/)
+and [here] (https://stackoverflow.com/questions/578406/what-is-the-ultimate-postal-code-and-zip-regex).
 
-- PhoneNumber
-- PostalCode
-- BLOB
+Which gives us the following countries:
 
-These all have challenges in terms of making them globally useful so they need a bit of thought.
+- US - United States
+- UK - United Kingdom
+- DE - Germany
+- CA - Canada
+- FR - France
+- IT - Italy
+- AU - Australia
+- NL - Netherlands
+- ES - Spain
+- DK - Denmark
+- SE - Sweden
+- BE - Belgium
+- IN - India
 
-For `PhoneNumber` we can probably just use the [E.164 specification](https://en.wikipedia.org/wiki/E.164)
-which is simply `+17895551234`. The very powerful
-[`libphonenumber` library](https://github.com/googlei18n/libphonenumber) is available to take
-_that_ format, parse and display it in whatever display format you want. It can also be used to
-parse user input and _get_ the E.164 format to pass _into_ a schema.
+This is really a practical decision of weight (of the package) vs. completeness.
 
-Postal codes are [a bit more involved](https://en.wikipedia.org/wiki/List_of_postal_codes). But,
-again, it's probably just a really long regex.
+In the future we might expand this list and use the more comprehensive list found [here] (http://unicode.org/cldr/trac/browser/tags/release-26-0-1/common/supplemental/postalCodeData.xml).
+
+
+## Future
+We'd like to keep growing this package, within reason, to include the scalar types that are widely
+required when defining GraphQL schemas. We welcome both suggestions and pull requests. One idea
+we're considering is:
 
-BLOBs could be a base64-encoded object of some kind.
+- BLOB, could be could be a base64-encoded object of some kind
 
 ## What's this all about?
 GraphQL is a wonderful new approach to application data and API layers that's gaining momentum. If