Docs: Update all local links in README files to work with npm (WordPr…

…ess#13030)

* Docs: Update all local links in README files to work with npm

* Update packages/blocks/README.md

* Fix new lines in blocks README file

* Revert nux component link

* Revert link to the block library

* Update link to component from edit-post package

packages/block-serialization-default-parser/README.md

@@ -1,6 +1,6 @@
 # Block Serialization Default Parser
 
-This library contains the default block serialization parser implementations for WordPress documents. It provides native PHP and JavaScript parsers that implement the [specification](../../docs/grammar.md) from [`@wordpress/block-serialization-spec-parser`](../block-serialization-spec-parser/README.md) and which normally operates on the document stored in `post_content`.
+This library contains the default block serialization parser implementations for WordPress documents. It provides native PHP and JavaScript parsers that implement the [specification](/docs/contributors/grammar.md) from [`@wordpress/block-serialization-spec-parser`](/packages/block-serialization-spec-parser/README.md) and which normally operates on the document stored in `post_content`.
 
 ## Installation
 

packages/block-serialization-spec-parser/README.md

@@ -1,6 +1,6 @@
 # Block Serialization Spec Parser
 
-This library contains the grammar file (`grammar.pegjs`) for WordPress posts which is a block serialization [_specification_](../../docs/grammar.md) which is used to generate the actual _parser_ which is also bundled in this package.
+This library contains the grammar file (`grammar.pegjs`) for WordPress posts which is a block serialization [_specification_](/docs/contributors/grammar.md) which is used to generate the actual _parser_ which is also bundled in this package.
 
 PEG parser generators are available in many languages, though different libraries may require some translation of this grammar into their syntax. For more information see:
 

packages/blocks/README.md

@@ -1,18 +1,10 @@
 # Blocks
 
-"Block" is the abstract term used to describe units of markup that, composed
-together, form the content or layout of a webpage. The idea combines concepts
-of what in WordPress today we achieve with shortcodes, custom HTML, and embed
-discovery into a single consistent API and user experience.
+"Block" is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage. The idea combines concepts of what in WordPress today we achieve with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.
 
-For more context, refer to
-[_What Are Little Blocks Made Of?_](https://make.wordpress.org/design/2017/01/25/what-are-little-blocks-made-of/)
-from the
-[Make WordPress Design](https://make.wordpress.org/design/)
-blog.
+For more context, refer to [_What Are Little Blocks Made Of?_](https://make.wordpress.org/design/2017/01/25/what-are-little-blocks-made-of/) from the [Make WordPress Design](https://make.wordpress.org/design/) blog.
 
-The following documentation outlines steps you as a developer will need to
-follow to add your own custom blocks to WordPress's editor interfaces.
+The following documentation outlines steps you as a developer will need to follow to add your own custom blocks to WordPress's editor interfaces.
 
 ## Installation
 
@@ -26,14 +18,9 @@ _This package assumes that your code will run in an **ES2015+** environment. If
 
 ## Getting Started
 
-If you're not already accustomed to working with JavaScript in your WordPress
-plugins, you may first want to reference the guide on
-[_Including CSS & JavaScript_](https://developer.wordpress.org/themes/basics/including-css-javascript/)
-in the Theme Handbook.
+If you're not already accustomed to working with JavaScript in your WordPress plugins, you may first want to reference the guide on [_Including CSS & JavaScript_](https://developer.wordpress.org/themes/basics/including-css-javascript/) in the Theme Handbook.
 
-At a minimum, you will need to enqueue scripts for your block as part of a
-`enqueue_block_editor_assets` action callback, with a dependency on the
-`wp-blocks` and `wp-element` script handles:
+At a minimum, you will need to enqueue scripts for your block as part of a `enqueue_block_editor_assets` action callback, with a dependency on the `wp-blocks` and `wp-element` script handles:
 
 ```php
 <?php
@@ -49,65 +36,34 @@ function myplugin_enqueue_block_editor_assets() {
 add_action( 'enqueue_block_editor_assets', 'myplugin_enqueue_block_editor_assets' );
 ```
 
-The `enqueue_block_editor_assets` hook is only run in the Gutenberg editor
-context when the editor is ready to receive additional scripts and stylesheets.
-There is also an `enqueue_block_assets` hook which is run under __both__ the
-editor and front-end contexts.  This should be used to enqueue stylesheets
-common to the front-end and the editor.  (The rules can be overridden in the
-editor-specific stylesheet if necessary.)
-
-The following sections will describe what you'll need to include in `block.js`
-to describe the behavior of your custom block.
-
-Note that all JavaScript code samples in this document are enclosed in a
-function that is evaluated immediately afterwards.  We recommend using either
-ES6 modules
-[as used in this project](https://wordpress.org/gutenberg/handbook/reference/coding-guidelines/#imports)
-(documentation on setting up a plugin with Webpack + ES6 modules coming soon)
-or these
-["immediately-invoked function expressions"](https://en.wikipedia.org/wiki/Immediately-invoked_function_expression)
-as used in this document.  Both of these methods ensure that your plugin's
-variables will not pollute the global `window` object, which could cause
-incompatibilities with WordPress core or with other plugins.
+The `enqueue_block_editor_assets` hook is only run in the Gutenberg editor context when the editor is ready to receive additional scripts and stylesheets. There is also an `enqueue_block_assets` hook which is run under __both__ the editor and front-end contexts.  This should be used to enqueue stylesheets common to the front-end and the editor.  (The rules can be overridden in the editor-specific stylesheet if necessary.)
+
+The following sections will describe what you'll need to include in `block.js` to describe the behavior of your custom block.
+
+Note that all JavaScript code samples in this document are enclosed in a function that is evaluated immediately afterwards.  We recommend using either ES6 modules [as used in this project](https://wordpress.org/gutenberg/handbook/reference/coding-guidelines/#imports) (documentation on setting up a plugin with Webpack + ES6 modules coming soon) or these ["immediately-invoked function expressions"](https://en.wikipedia.org/wiki/Immediately-invoked_function_expression) as used in this document.  Both of these methods ensure that your plugin's variables will not pollute the global `window` object, which could cause incompatibilities with WordPress core or with other plugins.
 
 ## Example
 
-Let's imagine you wanted to define a block to show a randomly generated image
-in a post's content using
-[lorempixel.com](http://lorempixel.com/).
-The service provides a choice of category and you'd like to offer this as an
-option when editing the post.
+Let's imagine you wanted to define a block to show a randomly generated image in a post's content using [lorempixel.com](http://lorempixel.com/). The service provides a choice of category and you'd like to offer this as an option when editing the post.
 
 Take a step back and consider the ideal workflow for adding a new random image:
 
 - Insert the block.  It should be shown in some empty state, with an option to choose a category in a select dropdown.
 - Upon confirming my selection, a preview of the image should be shown next to the dropdown.
 
-At this point, you might realize that while you'd want some controls to be
-shown when editing content, the markup included in the published post might not
-appear the same (your visitors should not see a dropdown field when reading
-your content).
+At this point, you might realize that while you'd want some controls to be shown when editing content, the markup included in the published post might not appear the same (your visitors should not see a dropdown field when reading your content).
 
 This leads to the first requirement of describing a block:
 
-__You will need to provide implementations both for what's to be shown in an
-editor and what's to be saved with the published content__.
+__You will need to provide implementations both for what's to be shown in an editor and what's to be saved with the published content__.
 
-To eliminate redundant effort here, share common behaviors by splitting your
-code up into
-[components](../element).
+To eliminate redundant effort here, share common behaviors by splitting your code up into [components](/packages/element/README.md).
 
-Now that we've considered user interaction, you should think about the
-underlying values that determine the markup generated by your block. In our
-example, the output is affected only when the category changes. Put another
-way: __the output of a block is a function of its attributes__.
+Now that we've considered user interaction, you should think about the underlying values that determine the markup generated by your block. In our example, the output is affected only when the category changes. Put another way: __the output of a block is a function of its attributes__.
 
-The category, a simple string, is the only thing we require to be able to
-generate the image we want to include in the published content. We call these
-underlying values of a block instance its __attributes__.
+The category, a simple string, is the only thing we require to be able to generate the image we want to include in the published content. We call these underlying values of a block instance its __attributes__.
 
-With these concepts in mind, let's explore an implementation of our random
-image block:
+With these concepts in mind, let's explore an implementation of our random image block:
 
 ```php
 <?php
@@ -199,7 +155,7 @@ Let's briefly review a few items you might observe in the implementation:
   your plugin. This helps prevent conflicts when more than one plugin registers
   a block with the same name.
 - You will use `createElement` to describe the structure of your block's
-  markup. See the [Element documentation](../element/README.md) for more
+  markup. See the [Element documentation](/packages/element/README.md) for more
   information.
 - Extracting `RandomImage` to a separate function allows us to reuse it in both
   the editor-specific interface and the published content.
@@ -210,34 +166,17 @@ Let's briefly review a few items you might observe in the implementation:
 - React provides conveniences for working with `select` element with
   [`value` and `onChange` props](https://facebook.github.io/react/docs/forms.html#the-select-tag).
 
-By concerning yourself only with describing the markup of a block given its
-attributes, you need not worry about maintaining the state of the page, or how
-your block interacts in the context of the surrounding editor.
-
-But how does the markup become an object of attributes? We need a pattern for
-encoding the values into the published post's markup, and then retrieving them
-the next time the post is edited. This is the motivation for the block's
-`attributes` property. The shape of this object matches that of the attributes
-object we'd like to receive, where each value is a
-[__source__](http://github.com/aduth/hpq)
-which tries to find the desired value from the markup of the block.
-
-In the random image block above, we've given the `alt` attribute of the image a
-secondary responsibility of tracking the selected category. There are a few
-other ways we could have achieved this, but the category value happens to work
-well as an `alt` descriptor. In the `attributes` property, we define an object
-with a key of `category` whose value tries to find this `alt` attribute of the
-markup. If it's successful, the category's value in our `edit` and `save`
-functions will be assigned. In the case of a new block or invalid markup, this
-value would be `undefined`, so we adjust our return value accordingly.
+By concerning yourself only with describing the markup of a block given its attributes, you need not worry about maintaining the state of the page, or how your block interacts in the context of the surrounding editor.
+
+But how does the markup become an object of attributes? We need a pattern for encoding the values into the published post's markup, and then retrieving them the next time the post is edited. This is the motivation for the block's `attributes` property. The shape of this object matches that of the attributes object we'd like to receive, where each value is a [__source__](http://github.com/aduth/hpq) which tries to find the desired value from the markup of the block.
+
+In the random image block above, we've given the `alt` attribute of the image a secondary responsibility of tracking the selected category. There are a few other ways we could have achieved this, but the category value happens to work well as an `alt` descriptor. In the `attributes` property, we define an object with a key of `category` whose value tries to find this `alt` attribute of the markup. If it's successful, the category's value in our `edit` and `save` functions will be assigned. In the case of a new block or invalid markup, this value would be `undefined`, so we adjust our return value accordingly.
 
 ## API
 
 ### `wp.blocks.registerBlockType( name: string, typeDefinition: Object )`
 
-Registers a new block provided a unique name and an object defining its
-behavior. Once registered, the block is made available as an option to any
-editor interface where blocks are implemented.
+Registers a new block provided a unique name and an object defining its behavior. Once registered, the block is made available as an option to any editor interface where blocks are implemented.
 
 - `title: string` - A human-readable
   [localized](https://codex.wordpress.org/I18n_for_WordPress_Developers#Handling_JavaScript_files)
@@ -275,5 +214,4 @@ Returns type definitions associated with a registered block.
 
 Returns settings associated with a registered control.
 
-
 <br/><br/><p align="center"><img src="https://s.w.org/style/images/codeispoetry.png?1" alt="Code is Poetry." /></p>

packages/components/src/menu-item/README.md

@@ -1,6 +1,6 @@
 # MenuItem
 
-MenuItem is a component which renders a button intended to be used in combination with the [DropdownMenu component](../dropdown-menu).
+MenuItem is a component which renders a button intended to be used in combination with the [DropdownMenu component](/packages/components/src/dropdown-menu/README.md).
 
 ## Usage
 
@@ -23,7 +23,7 @@ const MyMenuItem = withState( {
 
 ## Props
 
-MenuItem supports the following props. Any additional props are passed through to the underlying [Button](../button) or [IconButton](../icon-button) component.
+MenuItem supports the following props. Any additional props are passed through to the underlying [Button](/packages/components/src/button/README.md) or [IconButton](/packages/components/src/icon-button/README.md) component.
 
 ### `children`
 
@@ -57,14 +57,14 @@ Refer to documentation for [`label`](#label).
 - Type: `string`
 - Required: No
 
-Refer to documentation for [IconButton's `icon` prop](../icon-button/README.md#icon).
+Refer to documentation for [IconButton's `icon` prop](/packages/components/src/icon-button/README.md#icon).
 
 ### `shortcut`
 
 - Type: `string`
 - Required: No
 
-Refer to documentation for [Shortcut's `shortcut` prop](../shortcut/README.md#shortcut).
+Refer to documentation for [Shortcut's `shortcut` prop](/packages/components/src/shortcut/README.md#shortcut).
 
 ### `role`
 

packages/components/src/tooltip/README.md

@@ -36,7 +36,7 @@ The direction in which the tooltip should open relative to its parent node. Spec
 
 The element to which the tooltip should anchor.
 
-__NOTE:__ You must pass only a single child. Tooltip renders itself as a clone of `children` with a [`Popover`](../popover) added as an additional child.
+__NOTE:__ You must pass only a single child. Tooltip renders itself as a clone of `children` with a [`Popover`](/packages/components/src/popover/README.md) added as an additional child.
 
 - Type: `Element`
 - Required: Yes

packages/core-data/README.md

@@ -1,8 +1,8 @@
 # Core Data
 
-Core Data is a [data module](../data) intended to simplify access to and manipulation of core WordPress entities. It registers its own store and provides a number of selectors which resolve data from the WordPress REST API automatically, along with dispatching action creators to manipulate data.
+Core Data is a [data module](/packages/data/README.md) intended to simplify access to and manipulation of core WordPress entities. It registers its own store and provides a number of selectors which resolve data from the WordPress REST API automatically, along with dispatching action creators to manipulate data.
 
-Used in combination with features of the data module such as [`subscribe`](https://github.com/WordPress/gutenberg/tree/master/packages/data#subscribe-function) or [higher-order components](https://github.com/WordPress/gutenberg/tree/master/packages/data#higher-order-components), it enables a developer to easily add data into the logic and display of their plugin.
+Used in combination with features of the data module such as [`subscribe`](/packages/data/README.md#subscribe-function) or [higher-order components](/packages/data/README.md#higher-order-components), it enables a developer to easily add data into the logic and display of their plugin.
 
 ## Installation