docs: fix spelling and grammatical errors

.github/CODE_OF_CONDUCT.md

@@ -2,7 +2,7 @@
 
 As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
 
-We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, age, or religion.
+We are committed to making participation in this project a harassment-free experience for everyone, regardless of the level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, age, or religion.
 
 Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
 

.github/COMMIT_CONVENTION.md

@@ -58,24 +58,24 @@ The **header** is mandatory and the **scope** of the header is optional.
 
 ### Revert
 
-If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
+If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body, it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
 
 ### Type
 
-If the prefix is `feat`, `fix` or `perf`, it will appear in the changelog. However if there is any [BREAKING CHANGE](#footer), the commit will always appear in the changelog.
+If the prefix is `feat`, `fix` or `perf`, it will appear in the changelog. However, if there is any [BREAKING CHANGE](#footer), the commit will always appear in the changelog.
 
 Other prefixes are up to your discretion. Suggested prefixes are `docs`, `chore`, `style`, `refactor`, and `test` for non-changelog related tasks.
 
 ### Scope
 
-The scope could be anything specifying place of the commit change. For example `core`, `compiler`, `ssr`, `v-model`, `transition` etc...
+The scope could be anything specifying the place of the commit change. For example `core`, `compiler`, `ssr`, `v-model`, `transition` etc...
 
 ### Subject
 
-The subject contains succinct description of the change:
+The subject contains a succinct description of the change:
 
 * use the imperative, present tense: "change" not "changed" nor "changes"
-* don't capitalize first letter
+* don't capitalize the first letter
 * no dot (.) at the end
 
 ### Body

.github/CONTRIBUTING.md

@@ -24,13 +24,13 @@ Hi! I'm really excited that you are interested in contributing to Vue.js. Before
 
 - Make sure `npm test` passes. (see [development setup](#development-setup))
 
-- If adding new feature:
+- If adding a new feature:
   - Add accompanying test case.
-  - Provide convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.
+  - Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.
 
 - If fixing bug:
   - If you are resolving a special issue, add `(fix #xxxx[,#xxxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `update entities encoding/decoding (fix #3899)`.
-  - Provide detailed description of the bug in the PR. Live demo preferred.
+  - Provide a detailed description of the bug in the PR. Live demo preferred.
   - Add appropriate test coverage if applicable.
 
 ## Development Setup
@@ -59,7 +59,7 @@ $ npm run dev:test
 # build all dist files, including npm packages
 $ npm run build
 
-# run the full test suite, include linting / type checking
+# run the full test suite, include linting/type checking
 $ npm test
 ```
 
@@ -93,7 +93,7 @@ The default test script will do the following: lint with ESLint -> type check wi
 
   - **`core`**: contains universal, platform-agnostic runtime code.
 
-    The Vue 2.0 core is platform-agnostic. That is, code inside `core` is able to be run in any JavaScript environment, be it the browser, Node.js, or an embedded JavaScript runtime in native applications.
+    The Vue 2.0 core is platform-agnostic. That is, the code inside `core` is able to be run in any JavaScript environment, be it the browser, Node.js, or an embedded JavaScript runtime in native applications.
 
     - **`observer`**: contains code related to the reactivity system.
 

benchmarks/ssr/README.md

@@ -2,7 +2,7 @@
 
 This benchmark renders a table of 1000 rows with 10 columns (10k components), with around 30k normal elements on the page. Note this is not something likely to be seen in a typical app. This benchmark is mostly for stress/regression testing and comparing between `renderToString` and `renderToStream`.
 
-To view the results follow the run section. Note that the overall completion time for the results are variable, this is due to other system related variants at run time (available memory, processing power, etc). In ideal circumstances both should finish within similar results.
+To view the results follow the run section. Note that the overall completion time for the results is variable, this is due to other system related variants at run time (available memory, processing power, etc). In ideal circumstances, both should finish within similar results.
 
 `renderToStream` pipes the content through a stream which provides considerable performance benefits (faster time-to-first-byte and non-event-loop-blocking) over `renderToString`. This can be observed through the benchmark.
 

benchmarks/uptime/index.html

@@ -82,7 +82,7 @@
     </div>
     <script src="../../dist/vue.min.js"></script>
     <script>
-      // functional components are prefect for small, presentational components
+      // functional components are perfect for small, presentational components
       // and they are much more efficient than stateful ones.
       Vue.component('uptime-day', {
         props: ['day'],

dist/README.md

@@ -25,7 +25,7 @@
 
 If you need to compile templates on the fly (e.g. passing a string to the `template` option, or mounting to an element using its in-DOM HTML as the template), you will need the compiler and thus the full build.
 
-When using `vue-loader` or `vueify`, templates inside `*.vue` files are compiled into JavaScript at build time. You don't really need the compiler in the final bundle, and can therefore use the runtime-only build.
+When using `vue-loader` or `vueify`, templates inside `*.vue` files are compiled into JavaScript at build time. You don't really need the compiler in the final bundle, and can therefore, use the runtime-only build.
 
 Since the runtime-only builds are roughly 30% lighter-weight than their full-build counterparts, you should use it whenever you can. If you wish to use the full build instead, you need to configure an alias in your bundler.
 

packages/vue-template-compiler/README.md

@@ -37,7 +37,7 @@ Note the returned function code uses `with` and thus cannot be used in strict mo
   - Type: `boolean`
   - Default: `false`
 
-  Set this to true will cause the `errors` returned in the compiled result become objects in the form of `{ msg, start, end }`. The `start` and `end` properties are numbers that mark the code range of the error source in the template. This can be passed on to the `compiler.generateCodeFrame` API to generate code frame for the error.
+  Set this to true will cause the `errors` returned in the compiled result become objects in the form of `{ msg, start, end }`. The `start` and `end` properties are numbers that mark the code range of the error source in the template. This can be passed on to the `compiler.generateCodeFrame` API to generate a code frame for the error.
 
 - `whitespace`
   - Type: `string`
@@ -52,7 +52,7 @@ Note the returned function code uses `with` and thus cannot be used in strict mo
   If set to `'condense'`:
 
   - A whitespace-only text node between element tags is removed if it contains new lines. Otherwise, it is condensed into a single space.
-  - Consecutive whitespaces inside a non-whitespace-only text node is condensed into a single space.
+  - Consecutive whitespaces inside a non-whitespace-only text node are condensed into a single space.
 
   Using condense mode will result in smaller compiled code size and slightly improved performance. However, it will produce minor visual layout differences compared to plain HTML in certain cases.