docs(concepts) entry points concepts typing according to styleguide; … (#3301)

* dpcs(concepts) entry points concepts typing according to styleguide; rework single entry list into continuation of paragraph

* Update src/content/concepts/entry-points.md

* Update src/content/concepts/entry-points.md

Author: EugeneHlushko

src/content/concepts/entry-points.md

@@ -15,7 +15,7 @@ As mentioned in [Getting Started](/guides/getting-started/#using-a-configuration
 
 ## Single Entry (Shorthand) Syntax
 
-Usage: `entry: string|Array<string>`
+Usage: `entry: string | [string]`
 
 __webpack.config.js__
 
@@ -44,7 +44,7 @@ This is a great choice when you are looking to quickly setup a webpack configura
 
 ## Object Syntax
 
-Usage: `entry: {[entryChunkName: string]: string|Array<string>}`
+Usage: `entry: { [entryChunkName] string [string] }`
 
 __webpack.config.js__
 
@@ -68,7 +68,7 @@ Below is a list of entry configurations and their real-world use cases:
 
 ### Separate App and Vendor Entries
 
-T> In webpack version < 4 it was common to add vendors as a separate entry point to compile it as a separate file (in combination with the `CommonsChunkPlugin`). <br><br> This is discouraged in webpack 4. Instead, the `optimization.splitChunks` option takes care of separating vendors and app modules and creating a separate file. __Do not__ create an entry for vendors or other stuff that is not the starting point of execution.
+T> In webpack version < 4 it was common to add vendors as a separate entry point to compile it as a separate file (in combination with the `CommonsChunkPlugin`). <br><br> This is discouraged in webpack 4. Instead, the [`optimization.splitChunks`](/configuration/optimization/#optimizationsplitchunks) option takes care of separating vendors and app modules and creating a separate file. __Do not__ create an entry for vendors or other stuff that is not the starting point of execution.
 
 ### Multi Page Application
 
@@ -86,8 +86,6 @@ module.exports = {
 
 __What does this do?__ We are telling webpack that we would like 3 separate dependency graphs (like the above example).
 
-__Why?__ In a multi-page application, the server is going to fetch a new HTML document for you. The page reloads this new document and assets are redownloaded. However, this gives us the unique opportunity to do multiple things:
-
-- Use `optimization.splitChunks` to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the number of entry points increases.
+__Why?__ In a multi-page application, the server is going to fetch a new HTML document for you. The page reloads this new document and assets are redownloaded. However, this gives us the unique opportunity to do things like using [`optimization.splitChunks`](/configuration/optimization/#optimizationsplitchunks) to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the number of entry points increases.
 
 T> As a rule of thumb: Use exactly one entry point for each HTML document.