chore: update deps (incl. prettier)

Author: Haroenv

.prettierignore

@@ -0,0 +1,4 @@
+js/build
+_site
+_sass/bootstrap
+css/main.scss

.prettierrc

@@ -0,0 +1,5 @@
+{
+  "singleQuote": true,
+  "trailingComma": "es5",
+  "proseWrap": "preserve"
+}

README.md

@@ -29,6 +29,7 @@ $ make serve
 ```
 
 On Windows, `make` is not available, so you need to execute `bundle` and `jekyll` directly:
+
 ```sh
 bundle install
 bundle exec jekyll serve --incremental

_posts/2016-11-24-offline-mirror.md

@@ -8,7 +8,7 @@ categories : announcements
 share_text : "installing node_modules with Yarn offline"
 ---
 
-Repeatable and reliable builds for large JavaScript projects  are vital.
+Repeatable and reliable builds for large JavaScript projects are vital.
 If your builds depend on dependencies being downloaded from network, this build system is neither repeatable nor reliable.
 
 One of the main advantages of Yarn is that it can install node_modules from files located in file system.
@@ -19,7 +19,6 @@ Caches store already unzipped tarballs downloaded from registry, they also can b
 The tarballs in “Offline mirror” can be consumed by any version Yarn that will build cache based on them.
 It is also easier to store files when they are compressed.
 
-
 ## Let's set up “Offline mirror” for a simple JS project
 
 ```json
@@ -36,7 +35,6 @@ It is also easier to store files when they are compressed.
 }
 ```
 
-
 When you run `yarn install`, the generated `yarn.lock` file has sections for every dependency:
 
 ```yaml
@@ -78,7 +76,7 @@ success Set "yarn-offline-mirror" to "./npm-packages-offline-cache".
 ✨  Done in 0.06s.
 ```
 
-> `./npm-packages-offline-cache` is an example location relative to home folder where all the source` .tar.gz` files will be downloaded to from the registry.
+> `./npm-packages-offline-cache` is an example location relative to home folder where all the source`.tar.gz` files will be downloaded to from the registry.
 
 Offline mirror does not come with removing tarballs. In order to keep the cache folder up to date, you need to add the following to the config file:
 
@@ -91,7 +89,6 @@ success Set "yarn-offline-mirror-pruning" to "true".
 ✨  Done in 0.06s.
 ```
 
-
 This will create a .yarnrc file in your HOME directory.
 Let's move this file to the project root so that offline mirror would be used only for this project.
 
@@ -153,26 +150,27 @@ is-array-1.0.1.tgz    left-pad-1.1.3.tgz    mime-db-1.25.0.tgz    mime-types-2.1
 ```
 
 > How can you test to make sure it is offline?
-- Clear your global cache with "yarn cache clean"
-- Turn off wifi
-- Run "yarn install --offline". The offline flag will make sure yarn does not reach out to the network
 
-> In a nutshell, to enable “Offline mirror” for your project you need:
-- add “yarn-offline-mirror” configuration to .yarnrc file
-- generate a new yarn.lock with “yarn install” command
+* Clear your global cache with "yarn cache clean"
+* Turn off wifi
+* Run "yarn install --offline". The offline flag will make sure yarn does not reach out to the network
 
+> In a nutshell, to enable “Offline mirror” for your project you need:
 
+* add “yarn-offline-mirror” configuration to .yarnrc file
+* generate a new yarn.lock with “yarn install” command
 
 ## A few tips and tricks
 
 ### Updating your package
 
 If you want to make sure you have a clean cached modules, here are few of the steps you can take:
-- Remove the package first. Make sure you have "yarn-offline-mirror-pruning" set to true in your .yarnrc file
-- Clear the yarn cache with "yarn cache clean" before adding the updated version of the package
-- Add your package
 
-The "yarn-offline-mirror-pruning" will help clean up any unlinked dependencies. When you add the updated package, it will check the yarn cache first and pull any missing dependencies from there. This will prevent yarn adding new tarball back with the updated package. You want to make sure the yarn cache is all clean before you do any adding for cache module. 
+* Remove the package first. Make sure you have "yarn-offline-mirror-pruning" set to true in your .yarnrc file
+* Clear the yarn cache with "yarn cache clean" before adding the updated version of the package
+* Add your package
+
+The "yarn-offline-mirror-pruning" will help clean up any unlinked dependencies. When you add the updated package, it will check the yarn cache first and pull any missing dependencies from there. This will prevent yarn adding new tarball back with the updated package. You want to make sure the yarn cache is all clean before you do any adding for cache module.
 
 ### You can check in “Offline mirror” into git or mercurial repository
 
@@ -186,7 +184,6 @@ For example, out of 849 React Native dependencies totaling 23MB, only 10% are la
 Many Facebook teams, including the React Native team, decided to check in their “Offline mirror”.
 They all share the same “Offline mirror” which means that most dependencies for new projects are often already checked into that folder, so the cost of storing the packages in source control gets lower the more projects use it.
 
-
 ### Let's compare checking in node_modules to checking in “Offline mirror”
 
 The React Native team used to check in the `node_modules` folder but they hit several limits:
@@ -263,8 +260,6 @@ Untracked files:
 no changes added to commit (use "git add" and/or "git commit -a")
 ```
 
-
-
 ### Did you know that Yarn is also distributed as a single bundle JS file in [releases](https://github.com/yarnpkg/yarn/releases) that can be used on CI systems without internet access?
 
 ![Files distributed with Yarn releases](/assets/posts/2016-11-24-offline-mirror/yarn-offline-blog-releases.png){:style="max-width: 700px"}
@@ -278,7 +273,6 @@ node ./yarn-0.23.2.js install
 
 This is quite convenient for teams that use multiple operating systems and want to have atomic updates for Yarn.
 
-
 ### This is going to get better
 
 The “Offline mirror” was implemented early in Yarn's development cycle and we are working on improving it in a backwards compatible way:

_posts/2016-12-01-lockfiles-for-all.md

@@ -14,9 +14,9 @@ you want to be sure that you're executing the same code across every system.
 
 Yarn maintains consistency across machines in two key ways:
 
-- Yarn uses a deterministic algorithm that builds up the entire dependency tree
+* Yarn uses a deterministic algorithm that builds up the entire dependency tree
   before placing files where they need to be.
-- Important info from the install process is stored in the `yarn.lock` lockfile
+* Important info from the install process is stored in the `yarn.lock` lockfile
   so that it can be shared between every system installing the dependencies.
 
 This lockfile contains information about the exact versions of every single
@@ -34,11 +34,11 @@ system designed around "breaking" or "non-breaking" changes.
 
 When you have a version such as `v1.2.3`, it's broken into three parts:
 
-- **Major (1.x.x)** – *Changes that may cause user code to break*
-- **Minor (x.2.x)** – *Changes that add new features (but should not break user
-  code)*
-- **Patch (x.x.3)** – *Changes that are fixing bugs in previous versions (but
-  do not add new features and should not break user code)*
+* **Major (1.x.x)** – _Changes that may cause user code to break_
+* **Minor (x.2.x)** – _Changes that add new features (but should not break user
+  code)_
+* **Patch (x.x.3)** – _Changes that are fixing bugs in previous versions (but
+  do not add new features and should not break user code)_
 
 When a package publishes a new version, the author bumps major, minor, or patch
 based on the changes that they have made as a way to communicate them.
@@ -47,7 +47,7 @@ Users of packages should typically welcome minor and patch versions but should
 be wary of major versions as they could break your code.
 
 Version ranges are a way of specifying which types of changes you want to
-accept and which versions you want to prevent.  These version ranges then
+accept and which versions you want to prevent. These version ranges then
 resolve down to a single version which is either the version you have installed
 or the latest published version that matches your version range.
 
@@ -61,7 +61,7 @@ for them to publish an accidental breaking change in a minor or patch version.
 If you install this breaking change when you don't intend to it could have bad
 consequences like breaking your app in production.
 
-Lockfiles *lock* the versions for every single dependency you have installed.
+Lockfiles _lock_ the versions for every single dependency you have installed.
 This prevents "Works On My Machine" problems, and ensures that you don't
 accidentally get a bad dependency.
 
@@ -73,10 +73,10 @@ you do not want that code to end up running without you knowing about it.
 
 There are two primary types of projects that use Yarn:
 
-- **Libraries** – *Projects that get published as packages to the registry and
-  installed by users. (i.e. React or Babel)*
-- **Applications** – *Projects that only consume other packages, typically
-  building some kind of product. (i.e. Your company's app)*
+* **Libraries** – _Projects that get published as packages to the registry and
+  installed by users. (i.e. React or Babel)_
+* **Applications** – _Projects that only consume other packages, typically
+  building some kind of product. (i.e. Your company's app)_
 
 For applications, most developers agree that lockfiles are A Good Idea™.
 But there has been some question about using them when building libraries.
@@ -88,14 +88,14 @@ within your dependencies will be ignored.
 
 It is important that Yarn behaves this way for two reasons:
 
-- You would never be able to update the versions of sub-dependencies because
+* You would never be able to update the versions of sub-dependencies because
   they would be locked by other `yarn.lock` files.
-- Yarn would never be able to fold (de-duplicate) dependencies so that
+* Yarn would never be able to fold (de-duplicate) dependencies so that
   compatible version ranges only install a single version.
 
 Some have wondered why libraries should use lockfiles at all if they do not and
 should not affect users. Even further, some have said that using lockfiles when
-developing libraries creates a *false sense of security* since your users could
+developing libraries creates a _false sense of security_ since your users could
 be installing different versions than you.
 
 This seems to logically makes sense, but let's dive deeper into the problem.
@@ -106,10 +106,10 @@ So far we've been talking about dependencies as if there were only one type of
 dependency when in fact there are several different types. These are broken
 down into two categories:
 
-- **Runtime** – *Dependencies that are used by the project's code and needed
-  when the code is run.*
-- **Development** – *Dependencies that are only needed to work directly on the
-  project*
+* **Runtime** – _Dependencies that are used by the project's code and needed
+  when the code is run._
+* **Development** – _Dependencies that are only needed to work directly on the
+  project_
 
 When a library is installed by a user, only the runtime dependencies are
 installed. The development dependencies are only ever installed when working
@@ -128,36 +128,36 @@ but it seems to hold true across every ecosystem. You almost always need more
 code to develop projects than you need to run them.
 
 When working on a library, it is far more likely that a development dependency
-breaks just because there are more of them that *could* break.
+breaks just because there are more of them that _could_ break.
 
 ## The Breaking Change Race
 
 When a package accidentally publishes a breaking change it starts the clock on
 who will be the first person to catch it. Whoever installs that breaking change
 first will (most likely) be the first to discover it.
 
-Let's *imagine* we have a package called `left-pad` which takes a string and
+Let's _imagine_ we have a package called `left-pad` which takes a string and
 adds a specified amount of padding in front of it. This small and seemingly
 harmless package is used by a really big project, which we'll just call...
 Babel.
 
-One day, the maintainer of  `left-pad`  decides they are going to do something
+One day, the maintainer of `left-pad` decides they are going to do something
 unspeakably evil and make it pad the right side instead. They publish it as a
 patch version which quickly spreads to everyone using it.
 
 Remember, Babel is a really huge project with tens of thousands of users and
 dozens of contributors. Let's try and figure out who will catch the padding
 fiasco first.
 
-- Looking at build history, Babel was installed in CI (with the `left-pad`
+* Looking at build history, Babel was installed in CI (with the `left-pad`
   dependency) exactly **103 times** in the last 30 days.
-- Looking at statistics from the registry, Babel was installed (with
+* Looking at statistics from the registry, Babel was installed (with
   `left-pad`) by users over **5.5 Million times** in the same 30 days.
 
 To put that in a different measurement:
 
-- Contributors install Babel on average **every 7 hours**
-- Users install Babel about on average **every 0.5 seconds**
+* Contributors install Babel on average **every 7 hours**
+* Users install Babel about on average **every 0.5 seconds**
 
 When the `left-pad` incident happened, users discovered it almost immediately.
 Notifying the Babel contributors via GitHub issues, tweets, Facebook messages,
@@ -187,7 +187,7 @@ suite the contributors can come up with.
 Users just write more code, and the code they write is not always what a
 library author will expect. The more popular the library the more edge cases
 users will find. Users will do things that you didn't even think was possible–
-it will *horrify* you. It will make you question the goodness of humanity.
+it will _horrify_ you. It will make you question the goodness of humanity.
 
 Even if a contributor happened to beat users to finding a breaking change,
 there's a pretty decent chance they won't catch it anyways. Untested edge cases
@@ -216,7 +216,7 @@ want to fix a bug or add a small feature to a library.
 ## The user's burden
 
 Of course not every breaking change is a development dependency, and
-theoretically contributors *could* catch breaking changes before users notice
+theoretically contributors _could_ catch breaking changes before users notice
 them. In that (narrow) scenario, aren't we shifting the burden from
 contributors to users?
 

_posts/2017-05-12-introducing-yarn.md

@@ -8,7 +8,6 @@ categories : announcements
 share_text : "Yarn Create & Yarn 1.0"
 ---
 
-
 Last year was a great time for Javascript newcomers! A lot of starter-kit projects were published, refined, and some of them eventually went on to offer command line tools dedicated to make project creation easier. One such example is [create-react-app](https://github.com/facebookincubator/create-react-app), but most frameworks have their own tools, with various flavors and syntaxes.
 
 Despite these tools, one problem remains: Users still need to know how to use their package managers before being able to start a new project. They need to know what's the difference between global packages and local packages, and how to make sure that the binaries are available from the shell, which can sometimes cause subtle issues. Further, because these globally installed tools need to be manually updated, most projects maintain a small cli wrapper that downloads the latest version of the tool itself. Fortunately, we're in a position where we can help with this to make building new applications more cohesive:
@@ -25,7 +24,7 @@ When ran, the create command will automatically install or update the requested
 
 It is important to us to keep the feature small and extensible. Yarn should be a lightweight tool and `yarn create` is no exception: An immediate implication is that the create command is a completely agnostic tool: we make no assumption regarding what you want to create, and delegate all the behavior to the `create-*` packages! It is our hope that the community will come up with creative way to use this tool. Creating apps is but only one thing! Feel free to make packages that create tests, readmes, changelogs or anything else you want!
 
-*Note: The `create-` prefix is inserted right before the package name. So, for example, if you run yarn create `@ng/app`, it will install the `@ng/create-app` package, then run it.*
+_Note: The `create-` prefix is inserted right before the package name. So, for example, if you run yarn create `@ng/app`, it will install the `@ng/create-app` package, then run it._
 
 ### Other Improvements
 

_posts/2017-05-31-determinism.md

@@ -34,7 +34,7 @@ supports-color@^3.2.3:
     has-flag "^1.0.0"
 ```
 
-This is the `yarn.lock `file generated by running the command `yarn add supports-color`. This file contains the version of supports-color that our project is using as well as the exact version of all its sub-dependencies.
+This is the `yarn.lock` file generated by running the command `yarn add supports-color`. This file contains the version of supports-color that our project is using as well as the exact version of all its sub-dependencies.
 
 With this lock file we can ensure that the version of `has-flag` that `supports-color` relies on is always the same version.
 
@@ -80,7 +80,7 @@ npm 5 introduces a rework of the shrinkwrap feature called package-lock. This fi
 }
 ```
 
-Note that here all the packages listed in the first dependencies object are hoisted. This means that npm can use only the package-lock as the source of truth in order to build the final dependency graph whereas Yarn needs the accompanying` package.json` to seed it.
+Note that here all the packages listed in the first dependencies object are hoisted. This means that npm can use only the package-lock as the source of truth in order to build the final dependency graph whereas Yarn needs the accompanying`package.json` to seed it.
 
 This means that npm has better assurances around hoisting position across npm versions at the cost of having a more dense lockfile. There’s currently no plan on how to support `package-lock.json` in Yarn as the story around lockfile interoperability is unclear. You could however imagine a future where Yarn supports both and updates them in tandem. We’re very interested in community feedback and encourage proposals for how this would work to be submitted as an [RFC](https://github.com/yarnpkg/rfcs).
 

_posts/2017-06-16-supporting-more-registries.md

@@ -8,7 +8,6 @@ categories : announcements
 share_text : "Yarn now supports even more private registries"
 ---
 
-
 Today, Yarn already supports a wide variety of different package feeds when fetching and downloading your dependencies. Up until now, there was however a small subset of public and private package feed providers that Yarn could not yet handle very well. One example of these package feed providers that were not yet supported was [Visual Studio Team Services](https://www.visualstudio.com/team-services/) (VSTS).
 
 Let's explain why:

_posts/2017-06-19-adding-command-line-aliases-for-yarn.md

@@ -16,7 +16,7 @@ Let’s say you check for package distribution tags information pretty often, ar
 
 ## Bash & Zsh
 
-[Bash](https://en.wikipedia.org/wiki/Bash_(Unix_shell)) is the default shell on most Unix-like systems; together with [Zsh](https://en.wikipedia.org/wiki/Z_shell), they both descended from the earlier [Bourne shell](https://en.wikipedia.org/wiki/Bourne_shell) and hence syntaxes are largely compatible. To add a simple alias in either Bash or Zsh, simply have the following line added into your `.bashrc` or `.zshrc`, respectively:
+[Bash](<https://en.wikipedia.org/wiki/Bash_(Unix_shell)>) is the default shell on most Unix-like systems; together with [Zsh](https://en.wikipedia.org/wiki/Z_shell), they both descended from the earlier [Bourne shell](https://en.wikipedia.org/wiki/Bourne_shell) and hence syntaxes are largely compatible. To add a simple alias in either Bash or Zsh, simply have the following line added into your `.bashrc` or `.zshrc`, respectively:
 
 ```sh
 alias ynf="yarn info --verbose --no-emoji"