fix(package): update prettier to v1.13.3

CONTRIBUTING.md

@@ -4,8 +4,8 @@
 
 Much of the [prelude of the Babel contribution guide](https://github.com/babel/babel/blob/7.0/CONTRIBUTING.md#not-sure-where-to-start) also applies for this project, since it operates on and with Babel plugins. In particular:
 
-* [AST Explorer](http://astexplorer.net/#/scUfOmVOG5) is a very useful tool for examining ASTs and prototyping plugins.
-* [The Babel Plugin handbook](https://github.com/thejameskyle/babel-handbook/blob/master/translations/en/plugin-handbook.md#babel-plugin-handbook) is a great resource for understanding Babel plugins.
+- [AST Explorer](http://astexplorer.net/#/scUfOmVOG5) is a very useful tool for examining ASTs and prototyping plugins.
+- [The Babel Plugin handbook](https://github.com/thejameskyle/babel-handbook/blob/master/translations/en/plugin-handbook.md#babel-plugin-handbook) is a great resource for understanding Babel plugins.
 
 This project is written with [TypeScript](https://www.typescriptlang.org/), a superset of JavaScript that allows explicit type annotations and includes a type checker.
 
@@ -59,6 +59,6 @@ We accept pull requests for bug fixes and improvements. For non-trivial changes
 
 ### A good pull request…
 
-* **Is tested.** Any bugs fixed should have a test that fails without the fix. Any features added should have tests covering the expected usage and expected failures.
-* **Is documented.** Reference any existing issues that your pull request addresses. Provide a reasonable description in the pull request body. Documentation of expected usage for new features is required. Documentation is generally not needed for bug-fix pull requests, but sometimes a bug happened because an API was poorly understood. Consider improving the documentation such that a similar bug would not be introduced in the future.
-* **Is narrow in scope.** Pull requests that make broad, sweeping changes are generally a bad idea. Instead, larger refactors or improvements should be broken down into multiple smaller pull requests.
+- **Is tested.** Any bugs fixed should have a test that fails without the fix. Any features added should have tests covering the expected usage and expected failures.
+- **Is documented.** Reference any existing issues that your pull request addresses. Provide a reasonable description in the pull request body. Documentation of expected usage for new features is required. Documentation is generally not needed for bug-fix pull requests, but sometimes a bug happened because an API was poorly understood. Consider improving the documentation such that a similar bug would not be introduced in the future.
+- **Is narrow in scope.** Pull requests that make broad, sweeping changes are generally a bad idea. Instead, larger refactors or improvements should be broken down into multiple smaller pull requests.

package.json

@@ -81,7 +81,7 @@
     "got": "^8.1.0",
     "mz": "^2.7.0",
     "pirates": "^3.0.2",
-    "prettier": "^1.12.1",
+    "prettier": "^1.13.3",
     "recast": "^0.14.7",
     "resolve": "^1.5.0",
     "source-map-support": "^0.5.3",

yarn.lock

@@ -3225,9 +3225,9 @@ prettier-check@^2.0.0:
   dependencies:
     execa "^0.6.0"
 
-prettier@^1.12.1:
-  version "1.12.1"
-  resolved "https://registry.npmjs.org/prettier/-/prettier-1.12.1.tgz#c1ad20e803e7749faf905a409d2367e06bbe7325"
+prettier@^1.13.3:
+  version "1.13.3"
+  resolved "https://registry.npmjs.org/prettier/-/prettier-1.13.3.tgz#e74c09a7df6519d472ca6febaa37cf7addb48a20"
 
 pretty-format@^22.4.3:
   version "22.4.3"