Merge pull request zloirock#527 from bernard-leech/patch-1

Some tiny typos

docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md

@@ -139,7 +139,7 @@ A popular issue was the big size (~2MB) of the `core-js` package and duplication
 
 In previous versions of `core-js`, modules with polyfills for stable ECMAScript features and ECMAScript proposals were prefixed with `es6.` and `es7.` respectively. It was a decision taken in 2014 when all the features which could be after ES6 were considered as ES7. In `core-js@3` all stable ECMAScript features are prefixed with `es.`, while ECMAScript proposals with `esnext.`.
 
-Almost all CommonJS entry points were changed. In `core-js@3` there are many more entry points than there were in `core-js@2`: they bring maxinum flexibility, making it possible to include only the polyfills needed by your application.
+Almost all CommonJS entry points were changed. In `core-js@3` there are many more entry points than there were in `core-js@2`: they bring maximum flexibility, making it possible to include only the polyfills needed by your application.
 
 Here are some examples of how the new entry points can be used:
 ```js
@@ -180,7 +180,7 @@ It's now possible to [configure the aggressiveness](https://github.com/zloirock/
 
 If a feature can't be implemented following the specification in every details, `core-js` adds a `.sham` property to the polyfill. For example, in IE11 `Symbol.sham` is `true`.
 
-No more LiveScript! When I started the `core-js` project, I mainly used [LiveScript](http://livescript.net/); after some time, I rewrote all the polyfills in JavaScript. Tests and helper tools in `core-js@2` still used LiveScript: it is a very interesting CoffeeScript-like language with powerful syntax sugar which allows writing very compact code, but now it's almost dead. Other than that, it was an additional barrier for contributing to `core-js` because a most `core-js` users do not know this language. `core-js@3` tests and tools use modern ES syntax: it could be a good moment to start contributing to `core-js` 🙂
+No more LiveScript! When I started the `core-js` project, I mainly used [LiveScript](http://livescript.net/); after some time, I rewrote all the polyfills in JavaScript. Tests and helper tools in `core-js@2` still used LiveScript: it is a very interesting CoffeeScript-like language with powerful syntax sugar which allows writing very compact code, but now it's almost dead. Other than that, it was an additional barrier for contributing to `core-js` because most `core-js` users do not know this language. `core-js@3` tests and tools use modern ES syntax: it could be a good moment to start contributing to `core-js` 🙂
 
 For almost all users, for optimization of `core-js` import, I recommend using [`babel`](#Babel). However, for some cases still useful [`core-js-builder`](http://npmjs.com/package/core-js-builder). Now it supports the `targets` argument which takes a [`browserslist`](https://github.com/browserslist/browserslist) query with target engines - you can create a bundle which contains only required for target engines polyfills. For cases like this, I made the [`core-js-compat`](http://npmjs.com/package/core-js-compat) package, more info about it you could find in [`@babel/preset-env` part of this article](#babelpreset-env).